Re: [hoc-devel] withAutoreleasePool in finalizers

[Daniel R. <da...@ph...>]

On Aug 25, 2008, at 8:29 AM, Gustav Munkby wrote:

> I'm implementing a HOC/Cocoa frontend for
> the Yi editor, and so far it works really well.
>
> I was puzzled about messages concerning
> autoreleasing without a pool in place. After
> some digging I have concluded that the
> problem was that there was no autorelease
> pool in place while finalizers were executed.

Hmm, there should always be an autorelease pool in place.  If you're  
not using one of apples built in event loops, you should allocate/ 
deallocate an autorelease pool in your main method.  That being said,  
not having finalizer autoreleased objects actually release until the  
program exits is probably unacceptable.

hmm, are these finalizers being run after the main method exits?  If  
so, it's actually safe to ignore those warnings.

> I tried wrapping the finalizers in
> withAutoreleasePool which removed the
> messages, but resulted in Yi crashing after
> some time when an autoreleasepool is
> deallocated twice. I can reproduce the
> error, but not predictably.

I'd really like to understand this error.   It would go a long way  
toward understanding if this is the "right way."  As far as I can  
tell, that should work.


> I then tried wrapping only the actual calls
> to release/dealloc in the finalizer, and with
> quite some testing I have not been able
> to reproduce the above failure.

While I don't understand why wrapping the finalizers didn't work, and  
that bugs me, this is more or less how you are supposed to use  
autorelease pools.

> I do not understand why this works, but
> this _is_ in the "Arcane Magic" section
> of HOC, so I guess I should not be too
> surprised. =)

Autorelease pools work by telling the runtime "I no longer need this  
object, but I'm pretty sure someone else is going to want it, so I'll  
just put a message in the pool, and go ahead an deallocate the object  
when the pool is released."  It's essentially a delayed release.  It's  
good practice to sprinkle your code with new autorelease pools  
whenever you're allocating then deallocating a large number of objects  
so that stuff is actually released and the memory is freed when you  
exit that section.  Otherwise you have to rely on the top level  
autorelease which is probably allocated in (or close too) your main  
method.

> Is this the right way to fix this problem?

Arguably, the right way is to side step the issue entirely and use  
garbage collected interfaces.  Otherwise yes, (other than not  
understanding why wrapping the entire finalizer didn't work).

Also, I don't believe dealloc is supposed to require an autorelease  
pool.  Though someone could always override dealloc and call  
autorelease and objective-c expects there to always be an autorelease  
pool available.

-- 
Daniel