> On Jul 14, 2017, at 12:22 PM, Charles Srstka <cocoa...@charlessoft.com> wrote: >> On Jul 14, 2017, at 10:09 AM, Jeremy Hughes <moon.rab...@virginmedia.com> >> wrote: >> >>> On 14 Jul 2017, at 14:40, Steve Christensen <puns...@mac.com >>> <mailto:puns...@mac.com>> wrote: >>> >>> On Jul 14, 2017, at 3:50 AM, Jeremy Hughes <moon.rab...@virginmedia.com >>> <mailto:moon.rab...@virginmedia.com>> 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 (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
