Question

NSAutoreleasePool .. should there be only one? Why would you want to have more then one? Would you ever want to have more than one pool as part of a single class?

If you have multiple pools, which one will contain object that was asked for be [autorelease]d? Is there a way to find out what objects are waiting to be auto-released as part of a pool?

Sorry for 20 questions, please help me understand this better

Answer 1

NSAutoreleasePool .. should there be
only one?

No, not necessarily. You may create as many autorelease pools as you want/need.

Why would you want to have more then
one? Would you ever want to have more
than one pool as part of a single
class?

The idea is to keep your memory “high water mark” as low as possible. Using autorelease is a bit of a cheat to defer releasing your object until “later”. Sometimes you know when “later” is — and in these cases, it’s probably smart to make your own autorelease pool.

What do I mean by all this? Well, imagine you had the following loop:

for (...)
{
     // 1 MB of objects are added to the autorelease pool by some code...
}

1 MB is a lot! If that code looped 20 times, you’d have 20MB of objects waiting to get released. Even worse, if it ran for an indefinite or indeterminate number of times your application may very well crash. If you know that code is self-contained you can force anything that gets put into an autorelease pool within that block to get released by creating your own autorelease pool manually, like so:

for (...)
{
     NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
     // 1 MB of objects are added to the autorelease pool by some code...
     [pool drain];
}

Now your “high water mark” is only 1MB instead of 20MB (or more!).

If you have multiple pools, which one
will contain object that was asked for
be [autorelease]d?

The most recent one.

Imagine having a global stack. When you init a new AutoreleasePool, it adds itself to this global stack of autorelease pools. When you call [xxx autorelease] on an object, the autorelease method peeks at the autorelease pool on the top of this stack and adds itself to that autorelease pool’s list of objects. When you call [pool drain], that pool loops through all of the references that have been added to it and it calls [xxx release] on all of them.

As BJ Homer points out, the stack in the paragraph above isn’t actually truly global – there is actually one stack per thread. But I couldn’t figure out how to rewrite the above paragraph and keep it easily understandable by using terms like “thread-local”… so… this addendum will have to suffice : )