Re: next round: glib thread safety proposal

[Jeff Garzik <jgarzik pobox com>]

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.

	Jeff