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

Kenny Leung kenny_leung at pobox.com
Mon Jan 16 19:59:12 CST 2017

It would also enable the testing of fatal conditions, which would be great.


> On Jan 16, 2017, at 5:25 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> On Jan 16, 2017, at 3:57 PM, David Waite via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> 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>
> -Chris
> _______________________________________________
> 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/20170116/1ef1ddbb/attachment.html>

More information about the swift-evolution mailing list