Re: next round: glib thread safety proposal

[Sebastian Wilhelmi <wilhelmi ira uka de>]

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....
 
> > 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. 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.

Bye
Sebastian
-- 
+--------------============####################============--------------+
| Sebastian Wilhelmi, Institute for Computer Design and Fault Tolerance, |
| University of Karlsruhe;  Building 20.20, Room 263,  D-76128 Karlsruhe |
| mail: wilhelmi@ira.uka.de;  fax: +49 721 370455;  fon: +49 721 6084353 |
+-----------------> http://goethe.ira.uka.de/~wilhelmi <-----------------+