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). 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.
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
