[squeak-dev] Exception handling and concurrency (was Re: Fw: Re: [ReviewRequest 2] Error-handling and use of `future`)

Frank Shearar frank.shearar at gmail.com
Mon Feb 19 01:52:16 UTC 2018


On 18 February 2018 at 07:12, Tony Garnock-Jones <tonyg at leastfixedpoint.com>
wrote:

> Hi Eliot,
>
> On 02/15/2018 07:34 PM, Eliot Miranda wrote:
> > One thing to think about is that, because exception handling in
> > Smalltalk is above the VM, exception handling does not have to be
> > limited to a stack-oriented propagation.  There is no reason why
> > promises could not keep track of their creating environments and that
> > exception propagation could be modified to cross promise boundaries,
> > searching for handlers within their originating contexts.
>
> Yes, that's a neat idea. I've been mulling over something similar,
> regarding callbacks attached to Promises. Sometimes it's OK to run them
> in the context of the UI process, but other times they really want to be
> run in the context of the process that was running at the time they were
> attached to the Promise. I'm still thinking about what the smallest
> change I can get away with might be.
>
> In general, exceptions per se - or rather, stack-based exception
> *handler* mechanisms - don't adapt well to a concurrent setting. Miller,
> Tribble and Shapiro's "Concurrency Among Strangers" (2005) [1] is great
> on this topic. Their idea of "plan interference" really captures the
> problem well.
>
>   [1] http://www.erights.org/talks/promises/paper/tgc05.pdf
>
> However, aside from the E-style techniques, an Erlang style design works
> quite well. There, stack-oriented exceptions and exception handlers cope
> with error signalling and recovery within a process, and Erlang's "link"
> mechanism propagates entire actor failures among processes. (In some
> ways this is reminiscent of E's two-layered design, with vats containing
> objects.)
>
> > Perhaps this is what the onRejected: mechanism does.  But I've wondered
> > for a few years (without playing, and so my thoughts are vapor and
> > probably quite ill-formed) that such a system could be more convenient.
>
> Yep. My recently-completed doctoral work was on a new actor/tuplespace
> inspired hybrid model of concurrency that in some ways makes things like
> error signalling and recovery less terrible. (See
> http://syndicate-lang.org/tonyg-dissertation/ if you're interested.)
>

Congratulations!


> > might be possible to have promises hold onto their originating
> > environments so that when an uncaught exception does occur in a promise
> > one can make sense of its history.
>
> Recording this kind of causal information is hard, but could be
> worthwhile. I don't yet have enough experience with Promises to be able
> to do the design work. I wonder if there's an overlap with "E-order".
> I've always had trouble digging through erights.org enough to get a
> clear picture on exactly what E-order entails.
>

C# Tasks (promises) routinely keep track of their "stack", for what it's
worth. I've never had a need to look into how exactly they do this, but
maybe that's an avenue to explore?

Debugging Task-based code never feels any different to debugging "normal"
code, FWIW. (Of course that may well be because I make sure my colleagues
use immutable data structures and all that...)

frank


> Cheers,
>   Tony
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180218/c39e1783/attachment.html>


More information about the Squeak-dev mailing list