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

[Dave Abrahams]

on Tue Jan 17 2017, Jonathan Hull <jhull-AT-gbis.com> wrote:

> Bringing it back towards the initial post, what if there was a
> separation from true needs-to-take-down-the-entire-system trapping and
> things like out-of-bounds and overflow errors which could stop at
> thread/actor bounds (or in some cases even be recovered)?
>
> The latter were the ones I was targeting with my proposal.  They live
> in this grey area, because honestly, they should be throwing errors if
> not for the performance overhead and usability issues.  

I fundamentally disagree with that statement.  There is value in
declaring certain program behaviors illegal, and in general for things
like out-of-bounds access and overflow no sensible recovery (where
“recovery” means something that would allow the program to continue
reliably) is possible.  

> My solution was to give the compiler a way to know that this was the
> desired behavior and optimize the throwing away unless it was
> explicitly requested.
>
> I guess another option would be to introduce a new concept for this
> grey type of error.  Maybe instead of ‘fatalError’ you have something
> with a different name saying “this should only take down the current
> actor”… and then you add a well defined process for cleanup.
>
> I would still really like to see the ability to turn this type of
> thing into normal throwing error handling, so maybe something like
> ‘fatalThrow’ which takes the same information as ‘throw’, so that it
> can be converted to a standard throw by the caller, but otherwise
> traps and takes down the actor.  That would make certain types of
> algorithms much simpler for me.
>
> Thanks,
> Jon
>
>> On Jan 17, 2017, at 11:49 AM, Dave Abrahams via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> on Mon Jan 16 2017, Chris Lattner <swift-evolution at swift.org
>> <mailto: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
>>> <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
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>

-- 
-Dave