> On 16 Nov 2016, at 18:06, Joe Groff via swift-evolution
> <[email protected]> wrote:
>
>>
>> On Nov 12, 2016, at 4:19 PM, David Sweeris via swift-evolution
>> <[email protected]> wrote:
>>
>>
>>> On Nov 10, 2016, at 12:39 PM, Stephen Canon via swift-evolution
>>> <[email protected]> wrote:
>>>
>>>> On Nov 10, 2016, at 1:30 PM, Dave Abrahams via swift-evolution
>>>> <[email protected]> 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
> [email protected] <mailto:[email protected]>
> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
