Re: abnormal thread termination

[Richard Frith-Macdonald]

> On 13 Jul 2015, at 10:40, David Chisnall <address@hidden> wrote:
> 
> On 13 Jul 2015, at 10:32, Richard Frith-Macdonald <address@hidden> wrote:
>> 
>>> 
>>> On 13 Jul 2015, at 09:57, David Chisnall <address@hidden> wrote:
>>> 
>>> On 10 Jul 2015, at 20:18, Riccardo Mottola <address@hidden> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I detach a thread "normally" with:
>>>> 
>>>> [updateButton setEnabled:NO];
>>>> [NSThread detachNewThreadSelector:@selector(updateData:) toTarget:self 
>>>> withObject:nil];
>>>> 
>>>> It executes everything as expected, but I continuously get:
>>>> WARNING thread 0x2c63c1a8 terminated without calling +exit!
>>>> 
>>>> I have done something similar with other threads and I don't get this 
>>>> error. What could be happening? Some sort of premature exit? It executes 
>>>> up to the last statement.
>>> 
>>> This message also appears for threads that are not created with NSThread, 
>>> which is quite annoying.  I use some of the C++11 threading support for 
>>> some worker threads and I get a message when they exit.
>> 
>> This message indicates a bug in the program as far as I can tell from 
>> looking at the source;
>> 
>> It’s generated by the handler set by pthread_key_create() and should only be 
>> called if the thread exits while the thread-specific data associate with the 
>> key (ie the NSThread object) is non-null.
>> 
>> When a thread is detached by NSThread, it runs a method and calls +exit when 
>> the method completes, and +exit destroys the NSThread object and sets the 
>> thread-specific data to null.
>> When a non-gnustep thread is used for gnustep code, there are two functions 
>> provided to register/deregister it (and the latter similarly destroys the 
>> NSThread instance and nulls-out the thread-specific variable).
>> 
>> So seeing the message means that a thread has somehow exited without 
>> cleaning up its gnustep related thread-specific data (thus leaking an 
>> NSThread instance and a presumably other related objects).
>> 
>> I don’t see how that can happen other than by an application level bug (ie 
>> some code in that thread calls pthread_exit() or something similar).
>> 
>> Of course, I may have missed spotting some race condition or logic error in 
>> the code … 
> 
> Hmm, I wasn’t quite correct - it does call Objective-C stuff, but:
> 
> - There is no autorelease pool on the thread
> - There are no references to NSThread
> - All memory management is handled by ARC / C++
> 
> In this case, NSThread should not need to be used - if it does internally, 
> then it should clean itself up on thread exit.  The same code works fine on 
> OS X without any warnings.

The fact that code happens to work on some version of OSX does not really mean 
it’s OK portable code.
We have a documented thread cleanup mechanism for a reason; it lets you write 
portable code; which is what gnustep is for.

Pragmatically speaking, you can’t assume that methods you call won’t call other 
methods/classes (so you can’t assume NSThread is not used).

We can fairly easily detect a thread which hasn’t been registered, and 
automatically register it (which is what happens, though I think explicitly 
registering is recommended as that lets you easily check to see if you already 
registered the thread), but we can’t easily write portable thread cleanup code 
which will work after a thread exits; something that works in the exit handler 
under one pthreads implementation may not work under another.

So, we have an easy option … app developer calls the function to deregister the 
thread before exiting from it
Or we have a hard option … someone figures out how to write portable code to 
perform cleanup within the pthread exit handler

I’d be quite happy if someone wanted to contribute portable thread cleanup code 
which would run safely on pthread_exit() of course.