Re: abnormal thread termination

[Niels Grewe]

> Am 15.01.2016 um 12:30 schrieb Richard Frith-Macdonald <address@hidden>:
> 
>> 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) …

I was thinking it could be done so that the entry is only present for the 
duration of the cleanup being done. So you’d insert it at the beginning of the 
destructor function, and remove it after the observers have run.

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

Great. I’ll look into it then!

Cheers,

Niels