|
From: | Richard Frith-Macdonald |
Subject: | Re: -[NSThread detachNewThread...] memory management question |
Date: | Wed, 18 Jan 2006 22:39:12 +0000 |
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 haveto ensure in all your code that no dealloc triggers indirectly an autorelease. This is a big task, because just about any string manipulation createsautoreleased objects.
Yes this is the expected behavior (see the MacOS-X documentation). 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. That's not a way I would code, but I can see that some people might want it.
However, while the documentation states that the method run in the thread must create and destroy its own autorelease pool, the GNUstep implementation actually destroys any autorelease pools that the method fails to destroy itsself. This has the side effect that, if the method fails to destroy an autorelease pool, the object (myInterestingObject) will be destroyed in the context of that pool. I don't know if MacOS-X does the same thing, but even if it doesn't you could make use of the feature in your code.
Alternatively, you could make sure that the dealloc method of your object creates a temporary autorelease pool while releasing all its ivars.
[Prev in Thread] | Current Thread | [Next in Thread] |