Re: abnormal thread termination

[Niels Grewe]

Hi guys,


> Am 15.01.2016 um 13:12 schrieb Niels Grewe <address@hidden>:
> 
>>> 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.

I’ve now implemented this and it turns out that it was necessary to do it this 
way. The reason is that pthread_t is an opaque type. It can be a simple scalar, 
a pointer, a struct, etc. That means if you can’t have a reasonable hash table 
for these: You have to do a linear search, calling pthread_equal() until you 
find the correct thread. So you want to keep the list as small as possible 
(i.e. only those thread concurrently undergoing cleanup). 

This is now in trunk and I’d like to invite people to test this on different 
platforms (especially on MinGW). This should only have an impact if you 
actually have threads where the NSThread object lingers in TLS on thread exit, 
that is if you have not called +exit or GSUnregisterCurrentThread(). There is a 
test case in Tests/base/NSThread, so you can just run gnustep-tests on that 
directory to see whether it’s working on your platform.

Thanks,

Niels