Re: nested autorelease pools?
Re: nested autorelease pools?
- Subject: Re: nested autorelease pools?
- From: John Stiles <email@hidden>
- Date: Tue, 1 Nov 2005 13:36:45 -0800
On Nov 1, 2005, at 12:34 PM, j o a r wrote:
On 1 nov 2005, at 21.16, Brian O'Brien wrote:
Does this look valid to you?
-(id) init
{
self = [super init];
mypool = [[NSAutoreleasePool alloc] init];
return self;
}
-(void) dealloc
{
[mypool release];
[super dealloc];
}
NSAutoreleasePool is a very special class, with special
requirements. The above is incorrect, because (as snipped from the
documentation of this class):
"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."
An autorelease pool lives in "execution scope", and not "object
scope".
I'm no expert here, but I suspect if we have a simple NSThread that's
used for one purpose, we can create an NSAutoreleasePool as it's
initialized and release the autorelease pool as the thread is
dealloced, and everything will work. I can't see how that could be a
problem.
I think the real reasons behind this warning in the documentation are
stacked NSAutoreleasePools. A thread's NSAutoreleasePools are
maintained in a stack, and if you perturb the order of the stack,
counterintuitive things happen—specifically, if you release a pool in
the middle of the stack, all the pools above it are implicitly
released as well. However, each thread gets its own unique stack, and
if your thread maintains the stack semantics correctly, I don't see
any problems occurring. And if a thread only ever created and
released a single NSAutoreleasePool, that's a pretty simple
degenerate case of a "stack" and everything ought to work fine.
See "Implications of Nested Autorelease Pools" for a more thorough
discussion.
But like I said, I'm no expert here. There may be other catches that
I'm missing. But I think the quoted warning in the documentation has
to do with the autorelease pools' stacking order.
_______________________________________________
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