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

Dave Abrahams dabrahams at apple.com
Tue Jan 17 13:49:15 CST 2017

on Mon Jan 16 2017, Chris Lattner <swift-evolution at swift.org> wrote:

>> On Jan 16, 2017, at 3:57 PM, David Waite via swift-evolution
> <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>

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.


More information about the swift-evolution mailing list