[swift-evolution] Preconditions aborting process in server scenarios [was: Throws? and throws!]

[Chris Lattner]

On Jan 18, 2017, at 10:45 AM, John McCall via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> That's certainly true of code that makes unaudited use of `unsafe` constructs that can violate safety without any checking. It's my hope that our normal safety checks are  thorough and fire early enough that your subprocess would crash before wide-system compromise happens. In an "actor" or similar model, even if we decide we don't want to pay for unwinding to fully clean up after the crashed actor, that crash could still at least be noted by a coordinator actor, which in your server situation could handle the problem by not accepting any new connections and letting its existing connections finish before restarting the process, or in an iOS-like mobile situation could  trigger serialization of the current user state so that the process can be transparently killed and restarted. In either situation, perhaps we'd want to "taint" actors that use unsafe constructs so that their failure can't be recovered at all.
> 
> This seems like basically the right approach to me.  It means we don't make any effort to "clean up" the failing actor — essentially, it's treated as if it were just deadlocked — which means we don't pay the pervasive code-size costs of unwinding.  That's even fairly likely to leave the process in a state that can still be usefully debugged (as opposed to unwinding stacks, which completely destroys the execution context).  But there's still an opportunity to react and try to wind up other tasks.
> 
> I'm not sure it makes any sense to call out actors that have used unsafe constructs as somehow specially unrecoverable.  If the concern is that the unsafe code may corrupt the other actors, well, that's true, but (1) that implies that you have to forbid recovery if *any* actor has used unsafe constructs, since low-level corruption can be passed between actors when they communicate normally, and (2) that's equally true of all sorts of high-level corruption that don't depend on unsafe constructs, and which the failing assertion may be the first indication of.

I agree with John on both points.  To the second, keep in mind that lots of safe constructs are built in terms of unsafe constructs  (e.g. Array).

-Chris

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