[e-lang] Events as Bad Ideas
markm at cs.jhu.edu
Sun Nov 28 13:20:24 EST 2004
(With the inclusion of the following, this email is also a valid updoc script.
You can otherwise ignore it.)
? def i := 3
# value: 3
? def j := 0
# value: 0
Jonathan S. Shapiro wrote:
> The point I was trying to make is simply that failure handling is
> orthogonal to the events vs. threads issue. No matter which scheme one
> uses, some mechanism is required to handle exceptional situations.
> My understanding was that a broken promise results from remote vat
> failure. That is, it is the result of some vat failing to compute an
> expected result because the remote vat has crashed or otherwise run out
> of resources.
> Have I misunderstood broken promises?
Ok, I see the confusion. You're half right. The case you're talking about is
when a partition causes an already resolved remote reference (a Far reference)
to transition to a Broken reference. It doesn't matter whether the partition
is caused by a crash or a genuine partition.
The other case is when an unresolved promise makes a transition directly to a
broken promise. For this case, the threads vs events issue is not orthogonal.
Let's contrast two expressions:
? def k := i.floorDivide(j) # can be abbreviated as i // j
# problem: <ArithmeticException: / by zero>
? def k := i <- floorDivide(j)
# value: <Promise>
If j is 0, the first example will throw an exception, terminating the normal
control flow, thereby causing k never to come into scope.
In the second example, we have arranged for the message "floorDivide(j)" to be
delivered to i in a separate (serializably later) event. Once this arrangement
is made, k is immediately bound to a promise for the value that will be
computed by this event. Control flow then proceeds in the current event
independent of what will be computed in this other event.
In this case, if j is 0, then this other event will throw an exception rather
than returning a value. In this case, the promise becomes broken rather than
fulfilled. It transitions directly to a broken reference reporting divide by zero.
? interp.waitAtTop(k) # pauses updoc script until k is resolved
# value: <ref broken by problem: <ArithmeticException: / by zero>>
Like non-signaling NaNs, broken references are contagious, allowing the
aggregation of exceptional state without getting in the way of pipelining. One
could think of a broken reference as "Not an Object", or "NanO". But "broken"
For more on this, please see
See especially <http://www.erights.org/elib/concurrency/refmech.html> for the
state transition diagram among the possible states of a reference in E.
Text by me above is hereby placed in the public domain
More information about the e-lang