Re: Who owns a child view controller?
Re: Who owns a child view controller?
- Subject: Re: Who owns a child view controller?
- From: Quincey Morris <email@hidden>
- Date: Fri, 14 Jul 2017 10:59:30 -0700
On Jul 14, 2017, at 03:50 , Jeremy Hughes <email@hidden> wrote:
>
> I’m still not entirely clear on when autorelease pools are used in Swift.
I think about it this way:
Autorelease is the run-time feature that provides an atomic return.
There is no such thing as an “atomic” return naturally built into in any of the
run-time environments using ARC (or MRC). That is, if a function result is a
reference-counted object, there is nothing that naturally prevents the
reference count from changing during the short window of mis-opportunity from
when a release occurs just before a callee returns, and the caller gets an
opportunity to retain the reference. That’s the price of multi-threading.
Therefore there are two practical solutions:
1. Retain the object over the window of mis-opportunity. This works fine if the
calling site is aware that the callee did it, and this is what happens when
both the caller and callee are using ARC conventions. In fact, with ARC, the
object is *already* retained in the callee, so this scenario doesn’t *add* a
retain, it *removes* a release (that would normally occur at the end of the
callee’s scope). And the caller doesn’t have to retain the result, just keep
the the release at the end of *its* scope. Win-win-win. Otherwise…
2. Retain and autorelease the object prior to returning. This works fine
always, because autorelease pools are per-thread, so there’s no change of it
being drained during the return process. But it typically adds a net return and
release.
Choosing a strategy is up to the callee, and is based on information about the
caller at run-time, not compile or link time. That means it’s not
source-language-specific. (The only exception would be if the Swift compiler
knew that a function was private and final, so it controlled both ends of the
call.)
_______________________________________________
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