Richard Frith-Macdonald <address@hidden> 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.