gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: -[NSThread detachNewThread...] memory management question


From: Richard Frith-Macdonald
Subject: Re: -[NSThread detachNewThread...] memory management question
Date: Thu, 19 Jan 2006 05:50:45 +0000


On 19 Jan 2006, at 01:23, Wim Oudshoorn wrote:

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.

Well, I think your suggestion (or something like it) Is a good one ...
I wrote a test program and ran it on MacOS-X, and the behavior there is that ..
1. anything autoreleased in the thread method gets leaked
2. anything autoreleased during deallocation of the target object is *not* leaked.

To me this seems very strange ... why not just create an autorelease pool whenever one is needed? Anyway, I suppose we want to mimic the actual MacOS-X behavior.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]