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: Wim Oudshoorn
Subject: Re: -[NSThread detachNewThread...] memory management question
Date: Thu, 19 Jan 2006 02:23:03 +0100
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/22.0.50 (darwin)

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.  
>
> 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.





reply via email to

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