Re: next round: glib thread safety proposal
- From: Jeff Garzik <jgarzik pobox com>
- To: wilhelmi ira uka de (Sebastian Wilhelmi)
- Cc: gtk-devel-list redhat com
- Subject: Re: next round: glib thread safety proposal
- Date: Tue, 1 Dec 1998 10:35:36 -0500 (EST)
Sebastian Wilhelmi wrote:
> Hi, Jeff
> > Take a look at my half-baked implementation. Check out
> > GLIB_1_1_4_THREADS branch. It includes pthread.h the Right Way(IMHO).
> > I didn't get very far with this, just made a few modules thread-safe.
> I already did, but we can't just use pthread.h, because it has got to be
> protable, thats what its all about....
My point was more that I included pthread.h when it was autodetected
at configure time, into glibconfig.h. You can do the same with
cthreads.h or whatever.
> > > Ah, this brings us to the point, you so far avoided to comment on: what
> > > about thread specific data? It would be nice to have (even though, to be
> > > honest, it is most certainly not much faster than mutexes).
> > Is this an issue? I've always handled this with logic. If a piece of
> > data doesn't belong on the thread's stack, I stick it into the main
> > dataspace while ensuring only that particular thread "knows" about it.
> yes, but how can that thread know about it.
Through the logic I code into the programs. It's quite simple...
> Thats what thread specific
> data means. you have a global key, shared by all threads and if you query
> with that key, every thread gets its own data location. that is kind of a
> resemblence of static vars, only with the obviuos advantage, that every
> thread has its own.
Can you give me a concrete example of where this would be useful?
If each thread needs its own data location, I g_malloc it. If each
thread needs access to a global structure, I wrap it in a mutex.
] [Thread Prev