on Mon Jan 16 2017, Chris Lattner <[email protected]> wrote:
>> On Jan 16, 2017, at 3:57 PM, David Waite via swift-evolution > <[email protected]> wrote: >> >> My interpretation is that he was advocating a future where a >> precondition’s failure killed less than the entire process. Instead, >> shut down some smaller portion like a thread, actor, or container > >> like .Net's app domains (which for those more familiar with >> Javascript could be loosely compared with Web Workers). >> >> Today - if you wanted a Swift server where overflowing addition >> didn’t interrupt your service for multiple users, you would need to >> use something like a pre-fork model (with each request handled by a >> separate swift process) >> >> That's the difference between CLI and desktop apps where the process >> is providing services for a single user, and a server where it may >> be providing a service for thousands or millions of users. > > Agreed, I’d also really like to see this some day. It seems like a > natural outgrowth of the concurrency model, if it goes the direction > of actors. > > If you’re interested, I speculated on this direction in this talk: > http://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf > <http://researcher.watson.ibm.com/researcher/files/us-lmandel/lattner.pdf> I totally support the idea of emergency shutown measures (e.g. save document for recovery), In general, though, when a precondition is violated, it means your program state is compromised in an arbitrarily bad way. Unfortunately, that applies equally across process boundaries as it does across thread boundaries, if there's some kind of static guarantee of safety as might be provided by actors. This means you need a way to make decisions about which kinds of precondition violations should be considered recoverable as long as you're willing to abandon the job, and which really do need to be fatal for the whole process... and I don't know if anyone's really ever figured that problem out. It'd be cool if Swift could solve it. -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
