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 >> <[email protected]> wrote: >> >> >> on Mon Jan 16 2017, Chris Lattner <[email protected] >> <mailto:[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 >>> <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] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> -- -Dave _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
