> On 6 Mar 2018, at 17:08, Ivan Vučica <i...@vucica.net> wrote:
> I was explaining refcounting and NSAutoreleasePool to someone, and I thought
> referencing GNUstep might be useful to explain the correct mental model of
> the behavior.
> But I'm confused about -drain in the non-ARC implementation:
> Won't equating drain and dealloc mean that pools will misbehave, and that
> after [pool drain], the incorrect pool will get populated (and later drained)?
> Am I correctly interpreting that this happens? If so, is it correct that this
> NSAutoreleasePool * outerPool = [NSAutoreleasePool new];
> [[NSObject new] autorelease]; // object 0 added to outerPool
> NSAutoreleasePool * innerPool = [NSAutoreleasePool new];
> [[NSObject new] autorelease]; // object 1 added to innerPool
> [innerPool drain]; // object 1 released; outerPool is the closest pool
> [[NSObject new] autorelease]; // object 2 added to outerPool
> [innerPool release]; // object 2 released, object 0 released; new pool
> created as the closest pool
> [outerPool release]; // no objects released; new pool created as the closest
> Unless I am missing something, object 0 would be released early here?
According to Apple, the -drain method is a synonym for -release (or -dealloc
since you don't retain autorelease pools).
So yes, if youi drain a pool the next time an object is autoreleased it goes
into the parent pool of the one you drained.
Your code above should crash at the point where you call [innerPool release]
since you are sending the -release message to a deallocated object.
I think the -drain method name is unintuitive. To me it sounds like it ought
to do the same as the gnustep-specific -emptyPool method (a more efficient
equivalent to draining/releasing the pool and immediately creating a new one).
Gnustep-dev mailing list