Re: Programatically detect if any autorelease pool exists?
Re: Programatically detect if any autorelease pool exists?
- Subject: Re: Programatically detect if any autorelease pool exists?
- From: Jim Correia <email@hidden>
- Date: Tue, 5 Sep 2006 18:26:40 -0400
On Sep 5, 2006, at 6:04 PM, Sean McBride wrote:
Why is it problematic in the second case? That shouldn't cause any
problems.
It's somewhat hard to explain. Basically, it's a timing thing. The
library (vtk) creates its autorelease pool in the ctor of a C++ class
that displays a window (a simplification, but sufficient) and releases
the autorelease pool in the dtor. A client application may of course
create a vtk window at any point during its lifetime, and once it
does,
all other Obj-C objects (related to vtk or not) will end up in the vtk
pool. Then, if the vtk window is closed, that autorelease pool goes
away and flushes objects unrelated to vtk.
This is way worse than just a "timing" problem.
Autorelease pools are maintained in a stack.
From the documentation:
http://developer.apple.com/documentation/Cocoa/Reference/Foundation/
Classes/NSAutoreleasePool_Class/Reference/Reference.html
"An autorelease pool should always be released in the same context
(invocation of a method or function, or body of a loop) that it was
created."
http://developer.apple.com/documentation/Cocoa/Conceptual/MemoryMgmt/
Concepts/AutoreleasePools.html#//apple_ref/doc/uid/20000047-997594-
EGGBFFED
"If you release an autorelease pool that is not the top of the stack,
this causes all (unreleased) autorelease pools above it on the stack
to be released, along with all their objects. If you neglect to send
release to an autorelease pool when you are finished with it
(something not recommended), it is released when one of the
autorelease pools in which it nests is released."
Creating an autorelease pool in a constructor, and releasing it in a
destructor is not going to work when the lifetimes of objects "overlap".
Your choices here are to
a) create/release an autorelease pool inside of every "top-level"
method which generates autoreleased objects
b) document that the host application is responsible for autorelease
pool maintenance in its run loop
I'm certainly open to other ideas. I had really hoped that
NSApplicationLoad() would create a pool if none existed, but it
doesn't
seem to.
Even if it did, who would be responsible for releasing and replacing
the pool? Without someone periodically "draining" the autorelease
pool, your heap would grow unbounded.
Jim
_______________________________________________
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