[swift-evolution] [swift-evolution-announce] [Review] SE-0176: Enforce Exclusive Access to Memory

[Gmail]

> On 3 May 2017, at 22:06, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> 
>> On May 3, 2017, at 3:56 PM, Florent Bruneau <florent.bruneau at intersec.com> wrote:
>> 
>> 
>>> Le 3 mai 2017 à 17:23, John McCall <rjmccall at apple.com> a écrit :
>>> 
>>>> On May 3, 2017, at 3:42 AM, Florent Bruneau via swift-evolution <swift-evolution at swift.org> wrote:
>>>>> • What is your evaluation of the proposal?
>>>> 
>>>> +1. However, it's unclear to me what the dynamic enforcement will look like: will it trap, emit a warning, be catchable in a debugger, ... More details on the developer-facing interface of the dynamic enforcement would be nice.
>>> 
>>> It will trap.  That trap will of course be caught in the debugger, and hopefully the debugger will be able to deliver a nice debugging experience here.
>>> 
>>>>> • Is the problem being addressed significant enough to warrant a change to Swift?
>>>> 
>>>> The problem is significant, however I can see two significant downsides. The first is the source-breaking nature of the proposal. Breaking source is a problem by itself, but here I'm afraid the errors reporting won't be easily understandable, because "exclusivity" is kind of an advanced feature that won't be easily grasped by developers.
>>> 
>>> Our hope is that this will trigger very rarely and that we can make sure that there's suitable documentation for what it means.
>> 
>> I'm worrying this may trigger more often on beginners' code because beginners will experiment and write incorrect code more often than experimented dev who have learned idiomatic code patterns.
> 
> That's generally a very important concern.  I do think it's less likely to apply here because beginners are quite a bit less likely to be experimenting with oddly-nested inout arguments, or inout arguments at all.
> 
> John.

I think it would be fairly important to get a nice and helpful error message if the exclusivity is violated, for developers of all skill levels to understand what’s happening and to know what to do about it. I don’t know if it’s something that’s worth pointing out specifically or not.

/ David

> 
>> 
>>>> My second concern is the performance of the dynamic enforcement. How confident are you that the performance hit of the enforcement will not nullify the gain made by the enabling of more compile-time optimisations?
>>> 
>>> It's a performance trade-off where, unfortunately, the upsides and downsides will be seen in very different code.  Dynamic enforcement will kick in mostly for code that makes heavy use of mutable class properties, e.g. traditional Cocoa programming.  We expect that the optimization advantages will mostly be seen in code that makes heavy use of value types, especially copy-on-write value types like the standard library's data structures.  Of course, traditional Cocoa programming also does use a lot of dictionaries and arrays, so it's possible that the advantages will offset each other.
>>> 
>>> One direction we're exploring for dynamic enforcement is enabling it only in certain builds by default (e.g. debug configurations).  Unlike array bounds checks and integer overflows, exclusivity violations are generally not data-dependent:  it's usually true that just executing the code in any configuration will adequately test for dynamic exclusivity violations.  You can get them with races, of course, but the dynamic enforcement mechanisms we're looking at will probably not detect cross-thread violations anyway.  Of course, you can make a reasonable argument that not enabling dynamic enforcement checks in production builds would contradict Swift's general policy of "safe by default", so this is not a certain thing.  We would very much like to hear swift-evolution's thoughts about this.
>> 
>> I would go for disabling the dynamic checks in productions. The rational is mostly the little gain compared to the performance overhead.
>> 
>>>>> • Does this proposal fit well with the feel and direction of Swift?
>>>> 
>>>> Yes.
>>>> 
>>>>> • If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>>>>> • How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
>>>> 
>>>> Full read. BTW, there is a typo in the "Eliminating non-instantaneous accesses?" section, _Int_appendABunchOfStuff => _Array_appendABunchOfStuff
>>> 
>>> Thank you, this has been fixed.
>>> 
>>> John.
>>> 
>>>> 
>>>>> More information about the Swift evolution process is available at:
>>>>> 
>>>>> https://github.com/apple/swift-evolution/blob/master/process.md
>>>>> 
>>>>> 
>>>>> Thanks,
>>>>> Ben Cohen
>>>>> Review Manager
>>>>> 
>>>>> _______________________________________________
>>>>> swift-evolution-announce mailing list
>>>>> swift-evolution-announce at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution-announce
>>>> 
>>>> -- 
>>>> Florent Bruneau
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> 
>> 
>> -- 
>> Florent Bruneau
>> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170504/c6c07df9/attachment.html>