> Can you elaborate on these portability problems? I suppose there is some > wriggle room in the pthreads specification, but the only piece of unspecified > behaviour that seems related is the following: The spec does not tell you > when the TLS key will be set to NULL — is it before or after the destructor > runs? I’ve tested this on Mac OS and a couple of glibc versions, and there > pthread_getspecific() will no longer retrieve the value assigned to the TLS > key once the destructor starts running. So in fact the pthread_setspecific() > call at the end of unregisterActiveThread() is a no-op on these platforms, > and some of the comments on how destructors are handled lead me to believe > that that is the intended behaviour.
I think that’s exactly where we get variations. Historically I’m sure pthread_getspecific() has worked during thread exit on at least some systems (though for all I know, modern systrems may have gravitated towards a single common behaviour of having it return zero). > 2. pthread_self() still returns the correct thread while the destructor runs, > so you could populate a lookup table of threads currently undergoing cleanup, > and use that in +currentThread to look up the NSThread object if you can’t > get it via pthread_getspecific(). That sounds ideal if (and I think we can probably assume it) either pthread_getspecific() works or it returns zero. I’m not sure about a lookup table of just the threads undergoing cleanup though (how would it be populated) … it might need to be a table of all registered threads (with the cleanup removing threads from the table). Of course that would mean we have the overhead of a global lock to protect the table when registering and dregistering each thread, but that’s probably not a big enough overhead to worry about. So yes, that shoulds workable to me. _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
