Re: nested autorelease pools?
Re: nested autorelease pools?
- Subject: Re: nested autorelease pools?
- From: "Brian O'Brien" <email@hidden>
- Date: Tue, 1 Nov 2005 15:27:03 -0700
On 1-Nov-05, at 3:13 PM, John Stiles wrote:
On Nov 1, 2005, at 1:56 PM, j o a r wrote:
On 1 nov 2005, at 22.36, John Stiles wrote:
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.
As threads in general have one entry point, and one exit point,
I'm also not sure what the point of that non-standard, rule-
breaking, exercise would be? The simple pattern of bracketing the
method you run with your thread works well for this, don't you agree?
Can't disagree.
I think the real reasons behind this warning in the documentation
are stacked NSAutoreleasePools.
Yes, and the current autorelease pool is found by walking up the
stack.
Well, the more common phrasing is "the top of the stack," but I
know what you mean. (Walking usually implies pointer chasing of
some sort, like walking a linked list.)
Perhaps autorelease pools shouldn't be objects at all, but rather
some sort of ObjC language construct? Something similar to the new
syntax for exception handling:
@AutoreleasePool
{
// Stuff
}
And if you're in a tight loop and need to drain the pool every now
and then:
@AutoreleasePool
{
if (SomeCondition)
{
@DrainPool
}
}
I'm not exactly sure what the benefit here is, other than an
enforced release of the pool. If that's what you want, just use
Objective-C++ and create a C++ class. Its constructor can create
the pool, and you can make a method to drain your autorelease pool.
When it goes out of scope, the destructor can release the pool.
Taking advantage of scoped object lifetimes is a C++ specialty.
The reason I put the pool creation and release in the init and
dealloc methods is because there are other methods of the thread
class that allocated objects and I wanted to be sure that those other
objects were freed when the thread finalized...
_______________________________________________
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