On Jan 18, 2017, at 10:45 AM, John McCall via swift-evolution <[email protected]> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
