> On Jul 14, 2017, at 10:59 AM, Quincey Morris > <quinceymor...@rivergatesoftware.com> wrote: > >> On Jul 14, 2017, at 03:50 , Jeremy Hughes <moon.rab...@virginmedia.com> >> 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.
This description applies even in the absence of threads. There is always a "window of mis-opportunity" between the callee's last release and the caller's first retain. If this is the only reference to the object then it would be deallocated after the callee relinquishes ownership and before the caller can retake ownership. Some convention is necessary to keep the object alive across the return, whether or not there is a threat of thread interference. > 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.) The Swift compiler can avoid autorelease more often than that. Swift can use a simple callee-retain caller-release convention any time it knows that the function is not visible to Objective-C. That happens often. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
