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

Tony Garnock-Jones tonyg at leastfixedpoint.com
Sun Feb 18 15:12:39 UTC 2018


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.)

> 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.

Cheers,
  Tony


More information about the Squeak-dev mailing list