[swift-evolution] Contiguous Memory and the Effect of Borrowing on Safety

[Karl]

> On 16 Nov 2016, at 18:06, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On Nov 12, 2016, at 4:19 PM, David Sweeris via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>>> On Nov 10, 2016, at 12:39 PM, Stephen Canon via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>>> On Nov 10, 2016, at 1:30 PM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> What worries me is that if systems programmers are trying to get static
>>>> guarantees that there's no ARC traffic, they won't be willing to handle
>>>> a copyable thing that carries ownership.
>>> 
>>> FWIW, we (frequently) only need a static guarantee of no ARC traffic *within a critical section*. If we can guarantee that whatever ARC operations need to be done happen in a precisely-controlled manner at a known interface boundary, that’s often good enough.
>> 
>> “Critical section” is a phrase I normally associate with multi-threaded code… Do we need to start talking about concurrency to move this topic forward?
> 
> In a sense, yeah, ARC traffic is concurrent to the explicitly-written behavior of the program, since the compiler does not make strong guarantees about when exactly retains and releases occur. Releases in particular can trigger arbitrary code execution through deinitializers. The analogy to a critical section for not wanting an arbitrary deinitializer to run within a region seems apt.
> 
> -Joe
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>

This seems similar to the reasoning for _fixLifetime, isn’t it? (there’s no documentation about what _fixLifetime does or when you need it, but when I use it it’s to basically create a barrier, before which deinitialisers aren’t allowed to run)

- Karl
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161118/571ff3d5/attachment.html>