Re: Who owns a child view controller?
Re: Who owns a child view controller?
- Subject: Re: Who owns a child view controller?
- From: John McCall <email@hidden>
- Date: Fri, 14 Jul 2017 13:38:53 -0400
> On Jul 14, 2017, at 12:22 PM, Charles Srstka <email@hidden> wrote:
>> On Jul 14, 2017, at 10:09 AM, Jeremy Hughes <email@hidden>
>> wrote:
>>
>>> On 14 Jul 2017, at 14:40, Steve Christensen <email@hidden
>>> <mailto:email@hidden>> wrote:
>>>
>>> On Jul 14, 2017, at 3:50 AM, Jeremy Hughes <email@hidden
>>> <mailto:email@hidden>> wrote:
>>>>
>>>> I’m still not entirely clear on when autorelease pools are used in Swift.
>>>> There is a WWDC video which says that they’re used in code that interfaces
>>>> with Objective-C, but Greg Parker’s comments in this thread indicate that
>>>> autorelease is also used behind the scenes in native Swift code - except
>>>> that in many cases the compiler is able to optimise it out of existence.
>>>> Apple’s Swift book doesn’t mention autorelease.
>>>
>>> I think the hazard here is that you are trying to build a mental model of
>>> when to expect autorelease pools (or autorelease behavior in general) and
>>> when not to. Worse, that you might design your code to fit those
>>> expectations.
>>
>> Apple’s documentation states that there are times that you do want to
>> consider the memory effects of autorelease pools (and suggests adding your
>> own pools to prevent large accumulations of dead objects during loops) - so
>> knowing when they are used isn’t irrelevant.
>>
>> Also, ARC is described as “deterministic” - which I’m possibly
>> misinterpreting as meaning "behaves in a predictable way".
>>
>> Jeremy
>
> I’d interpret it as “behaves in a consistent way.” Predictable is subjective,
> especially when autorelease pools are involved.
The word I would use is "reproducible". As humans, we say something is
"predictable" when it's easy to say exactly what it's going to do, and like any
complex program, ARC doesn't generally live up to that — even I wouldn't claim
that level of understanding of, say, the optimizer. But if you have a problem
with ARC, you can usually reproduce it exactly: its implementation model
doesn't naturally create new inconsistencies where a program behaves
differently on different runs.
(There are some minor exceptions, of course. But the major sources of
inconsistencies between runs are just classic concurrency races that would
exist in your program without ARC. ARC may not introduce those, but it also
doesn't really eliminate them.)
Anyway, here's how I recommend approaching these questions of how you should
think about ARC.
ARC provides an abstract language model. Most things in computers do, from
user-level libraries down to the operating system and even ultimately the
processor. What this means is that there are rules to the abstraction that you
are expected to live by, and those rules are defined not in terms of how some
specific implementation happens to work but in terms of the higher-level
abstractions presented to you as a user of the interface. For example, you
should not rely on the exact numeric value of POSIX file descriptors, or the
ordering relationship between two pointers sequentially returned by malloc(),
or the zero-initialization of the stack at process launch, or the limitations
of load speculation in current CPU microarchitectures; you should follow the
rules laid out in the language, library, or processor documentation.
ARC does not make promises about reference counts or when exactly an object
will be deallocated. Instead, it makes promises about when an object won't be
deallocated, and those promises are mostly tied to whether the object is
currently held by a strong reference. If you're looking at your program and
trying to decide if it's correct, those rules are the only thing you should be
considering. In this light, it is pretty much never important to be asking
questions about whether an object is an autorelease pool. If ARC is keeping an
object alive by putting it in an autorelease pool, that's pretty much its
business, as far as correctness is concerned. *You* need to be thinking about
whether you have a strong reference to it.
None of that is to say that it's wrong to try to understand the details behind
abstractions. Especially with ARC, those details can matter a lot when you're
tracking down a bug. And it also matters a lot for performance; for example,
there are times when ARC does autorelease something to keep it alive, and if
that autorelease is burning you, you need to figure out why it's happening
before you can figure out how to avoid it. And of course it's also just
interesting. All I'm saying is that, once you've figured out your problem, you
have to go back to the abstraction to figure out how to fix it.
John.
_______________________________________________
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