On 13 Jul 2015, at 10:32, Richard Frith-Macdonald <richardfrithmacdon...@gmail.com> wrote: > >> >> On 13 Jul 2015, at 09:57, David Chisnall <david.chisn...@cl.cam.ac.uk> wrote: >> >> On 10 Jul 2015, at 20:18, Riccardo Mottola <riccardo.mott...@libero.it> >> 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. David -- Sent from my Difference Engine _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
