Re: abnormal thread termination

[Richard Frith-Macdonald]

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