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: "Sean McBride" <email@hidden>
- Date: Wed, 6 Sep 2006 11:35:10 -0400
- Organization: Rogue Research
Thanks to everyone for their replies... I'll cover everything in this post.
Jim Correia (email@hidden) on 2006-09-05 18:26 said:
>> 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.
>
> *SNIP*
>
>Creating an autorelease pool in a constructor, and releasing it in a
>destructor is not going to work when the lifetimes of objects "overlap".
You are absolutely right. Like I said, the current implementation is no
good. :)
>Your choices here are to
>
>a) create/release an autorelease pool inside of every "top-level"
>method which generates autoreleased objects
Ugh, there's too many of them.
>b) document that the host application is responsible for autorelease
>pool maintenance in its run loop
If this were a Mac-only thing, then I'd certainly go that way. But the
vtk lib is practically an Application Framework, having facilities to
create windows, process events, etc. One has to be able to create
'cross platform vtk apps' that know of nothing but vtk. Here's an example:
<http://public.kitware.com/VTK/example-code.php> (scroll to C++)
>> 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.
True. But at least a 'pool of last resort' (created very early) would
stop the errors about having 'no pool in place' and stop the freaky
crashes due to pools coming and going when they shouldn't. Alas, since
this is a library, I don't have access to main(), and unfortunately
there is no vtkinit() to do any setup in.
How about if I create a simple C++ class who's ctor checks if there is a
pool (via +autoreleasePoolExists-- thanks Jonathon!) and creates one if
there isn't one. Then I allocate a global/static instance of that
object. Then any app that links to the vtk library will have a 'pool of
last resort', created even before main(), right? Does that seem
reasonable? (nasty I know, but the current situation is worse.)
Thanks!
--
____________________________________________________________
Sean McBride, B. Eng email@hidden
Rogue Research www.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
_______________________________________________
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