Re: NSAutoreleasePool drain/dealloc
On 6 Mar 2018, at 17:24, Richard Frith-Macdonald wrote: > > 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). -drain was introduced with GC, where -release was optimised away in either the compiler or the runtime and never delivered. It allowed the GC implementation to use autorelease pools as a hint that there were a lot of short-lived objects to delete and have the same code work in non-GC mode. ARC fixed this a lot better by introducing the @autoreleasepool syntax, and should be used in all new code. David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSAutoreleasePool drain/dealloc
On Tue, Mar 6, 2018 at 5:24 PM, Richard Frith-Macdonald < richard.frith-macdon...@theengagehub.com> wrote: > > > 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. > Thank you! I guess I never read that part of the NSAutoreleasePool docs. > 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). > That's what I assumed it was doing: releasing the members of the pool, while not releasing the pool itself. Thank you! ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSAutoreleasePool drain/dealloc
> On 6 Mar 2018, at 17:08, Ivan Vučica wrote: > > Hi, > > 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: > > https://github.com/gnustep/libs-base/blob/b8185fa6c13172436c070ab3bf60b3f12bce433b/Source/NSAutoreleasePool.m#L546 > > 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 > happens? > > 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 > pool > > 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 Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
NSAutoreleasePool drain/dealloc
Hi, 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: https://github.com/gnustep/libs-base/blob/b8185fa6c13172436c070ab3bf60b3f12bce433b/Source/NSAutoreleasePool.m#L546 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 happens? 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 pool Unless I am missing something, object 0 would be released early here? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev