Re: Silly ARC question - explanation requested
Re: Silly ARC question - explanation requested
- Subject: Re: Silly ARC question - explanation requested
- From: Quincey Morris <email@hidden>
- Date: Wed, 04 Jun 2014 13:02:47 -0700
On Jun 4, 2014, at 12:24 , Alex Zavatone <email@hidden> wrote:
> His response was "Well, I was able to autorelease any offending bits within the loop without a problem, what's the big deal?"
I think the deeper problem is that a while loop of this kind in an asynchronously executed block is a bit of a code smell. Surely the first step is to refactor the code so that each iteration is a separate block invocation. You either queue these for execution on a parallel queue for multitasked execution, or on a serial queue if execution must be sequential**. (If the interior of the while loop was trivial, you might not do it that way, but if it’s allocating significant amounts of memory each iteration, and doing significant work, then block-per-iteration sounds more reasonable.)
Then, you can and should enclose each block’s code in an autorelease pool, which should stop memory accumulating.
In the context of your original question, the problem is that while you *might* be able to predict the autorelease behavior in regard to what you *think of* as the “final” autorelease, you don’t know for certain — when any frameworks or 3rd party code is involved — if there might be *other* life-sustaining references to the objects. It’s “autorelease” after all, not “autodealloc”. This is not really an ARC-related pitfall, but a GCD-related one, IMO.
** You can use counting dispatch semaphores if you want something in between — several blocks queued but not for every iteration at the same time.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden