On 20 Mar 2018, at 09:38, Wolfgang Lux <wolfgang....@gmail.com> wrote:
>
>> Am 20.03.2018 um 07:31 schrieb amon <a...@vnl.com>:
>
>> I did try coding
>> p=[NSAutoreleasePool new]; do something; [p release];
>> and in some cases it seemed to help. In others it did not.
>> I'll be digging deeper tomorrow and I will give the macros
>> you suggested a try.
>
> Just one word of warning. If you use this code (or the equivalent
> CREATE_AUTORELEASE_POOL macro), be sure to catch any exception that is raised
> in the "do something" code and make sure that the pool gets released, i.e.,
> use
> p = [NSAutoreleasePool new];
> @try {
> do something;
> }
> @finally {
> [p release];
> }
> Otherwise, you'll leak a whole autorelease pool on every exception raised in
> the do something part.
I don’t believe that this is true for either of the GNUstep implementations.
With the ARC-based implementation, if you pop a pool out of order then it will
implicitly pop all of pools pushed on top of it, though you may leak the
autorelease pool object itself. With the non-ARC-based version, pools are
organised in a linked list and so popping a pool that isn’t the top will
implicitly pop all of the others above it and destroy them.
In both cases, objects will stay in the pool for longer (increasing peak memory
usage and increasing the pause when a later pool is popped) but the
autoreleased objects will only be leaked if the top pool in a thread is not
correctly cleaned up.
David
_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnustep
