Re: Newbie question: autorelease sends autorelease
Re: Newbie question: autorelease sends autorelease
- Subject: Re: Newbie question: autorelease sends autorelease
- From: James Bucanek <email@hidden>
- Date: Wed, 22 Sep 2004 09:15:32 -0700
On 2004-09-22, at 05.25, James Bucanek wrote:
> First question: What happens to an object that gets autoreleased
> during the dealloc message of another object that is being released by
> an autorelease pool?
>
> Example:
>
> Object a retains object b.
>
> Object a gets autoreleased.
>
> When the NSAutoreleasePool gets dealloc'd, a gets released.
>
> The dealloc handler for a sends an autoreleas to b.
>
> What happens to b?
>
> (1) b gets added to the same NSAutoreleasePool that a belongs to, and
> that NSAutoreleasePool repeatedly releases objects until it is empty.
>
> (2) b gets added to some other (next higher?) autorelease pool.
>
> (3) b leaks.
j o a r wrote on Wednesday, September 22, 2004:
>On 2004-09-22, at 08.24, Chris Ridd wrote:
>
>> That's a good question, but I can't see any reason why a dealloc method
>> would ever autorelease something in the first place. There's no point -
>> autorelease is only useful if you're returning an object to someone
>> else,
>> and by definition dealloc doesn't do that.
>
>This is not true. The ability to autorelease objects can be useful also
>in cases where you're not returning objects. Take for example the case
>with the self contained window controller that should be released after
>it's window is closed. It's customary to autorelease it on
>"windowWillClose:". Autorelease is also often used in place of release
>to be able to alloc-init-autorelease on one single row - in order to
>create code that's easier to understand, and therefore maintain.
In my case, I was autoreleasing in the dealloc handler because the object hands out lots of references to the child object and I was afraid of releasing it immediately.
In retrospect, this was misguided. Any client that wants to hang onto one of the children should retain it, and I should be releasing the object in the dealloc handler.
j o a r wrote on Wednesday, September 22, 2004:
>I don't know how this is implemented. I would guess (a), or perhaps (b)
>- but very unlikely (c).
I posted this question to the list, because I was sure that someone would know the answer right off the top of their head. :)
In the endless pursuit of answers, and for those who have a ligitimate reason to autorelease a child object in dealloc, I wrote a test case to find out.
I created two classes, A and B. A creates and retains a child B, which will later be autoreleased in its dealloc handler. I create and autorelease a single A object. All this runs in a Cocoa command-line project that creates exactly one NSAutoreleasePool which is released just before the tool exits. So if NSAutoreleasePool doesn't dealloc b, there's no chance to do it later. And the answer is...
[Session started at 2004-09-22 08:51:13 -0700.]
A is going away...
A is gone.
B is going away...
B is gone.
(1) b gets added to the same NSAutoreleasePool that a belongs to, and that NSAutoreleasePool repeatedly releases objects until it is empty.
>I would be interested to know why it matters to you though? Are you
>tracking down leaks?
No, the structure I had in memory was a tree -- and a potentially a very deep one at that. It could contains dozens, if not hundreds, of layers. If I autorelease the children in the dealloc handler and they were NOT immediately released, this could have significant performance implications as it might take a hundred or more iterations before all of the children were disposed of.
--
James Bucanek <mailto:email@hidden>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden