Richard Frith-Macdonald <[EMAIL PROTECTED]> writes: > On 18 Jan 2006, at 15:51, Wim Oudshoorn wrote: > >> Hm it looks like I have found a very pitfall to leak memory >> when using -[NSThread detachNewThreadSelector:toTarget:withObject:] >> >> Suppose you have somewhere >> >> [NSThread detachNewTheadSelector.... >> ... >> withObject: myInterestingObject]; >> >> Now when the thread finished, myInterestingObject >> is send a release message. >> This release message is send WITHOUT having an autoreleasepool in >> place. >> So if the dealloc method of myInterestingObject, triggers >> an autorelease on another object this other object will leak. >> >> Is this expected behaviour? Because if it is you have >> to ensure in all your code that no dealloc triggers indirectly an >> autorelease. >> This is a big task, because just about any string manipulation >> creates >> autoreleased objects. > > Yes this is the expected behavior (see the MacOS-X documentation).
Hm, I can't that from the Mac OS X documentation, although I will immediately concede that it is a very plausible interpretation. > I would guess that the idea is to make sure that the overhead of > creating/destroying a thread is as small as possible to enable > application designs where a lot of threads are created/destroyed to > do very small tasks. But I think a sane implementation has hardly any overhead. For example NSAutoreleasePool can, when it discovers there is no autoreleasepool in place, check if the NSThread is currently exiting, and if that is the case create an autoreleasepool. The NSThread deallocing code can, after releasing the target and argument, check if suddenly an autoreleasepool is created and if that is the case empty it. The implementation will have, in case you don't have a complicated situation as additional overhead an extra check if an autoreleasepool is created. This is dwarfed by the rest of the overhead. > > Alternatively, you could make sure that the dealloc method of your > object creates a temporary autorelease pool while releasing all its > ivars. No, not really, we have generic code that will take an arbitrary argument, which can be quite complicated. So if you are right, and unfortunately I expect so, we have for all plausible arguments make sure that there are no autorelease in their dealloc method. I am not even sure if the base library is "autorelease" safe. Well, if it is the desired behaviour we have to do this, but it will be ugly having all these autoreleasepools in the dealloc methods. *sigh* it has been a bad day hunting multithreading bugs. Wim Oudshoorn. _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
