Preparing Mozart 1.4.0

[Bob Calco]

> 
> On Sun, Jun 29, 2008 at 01:27:44PM -0400, Bob Calco wrote:
> 
> > > The Fault module has also been redesigned and rewritten completely.
> > > Distribution-related exceptions and fault handlers have been
> discarded,
> > > because of their complexity and lack of modularity.  Fault watchers
> > > have
> > > been reduced to a simpler primitive: a stream of fault state for
> each
> > > entity.  The programmer can also provoke entity failure, which can
> be
> > > helpful for combining fault-tolerant abstractions.
> >
> > This is interesting. How does it compare to Erlang's OTP mechanisms
> for
> > fault-tolerance? Seems at once lower level and more expressive.
> 
> I hope this means oz gets something like erlang's process linking
> (which allows building up abstractions like erlang's supervisors).

BTW, on page 56 of the Raph's paper, note the following:

---
The power and simplicity of failure handling in Erlang was an inspiration
for our
work. Erlang provides asynchronous detection of permanent failures between
processes [Arm07]. Two processes can be linked together. When one of them
(say a) terminates normally or because of a failure, the other one (say b)
is
notified by the runtime system. By default, process b will die if a died
because
of a failure. However, if b is a system process, it will receive a message
of the
form {'EXIT',Pid,Why}, where Pid is the identifier of process a, and Why is
a
value that describes the reason why a died. A special built-in turns a
process
into a system process.
Erlang chose to model all failures as permanent failures, in accordance with
its philosophy of "Let it fail". That is, keeping the fault model simple
allows
the recovery algorithm to be simple as well. This simplicity is very
important
for correctness. We can see our model as an extension of Erlang's model with
temporary failures and with a fault stream. Furthermore, our model is
designed
for a richer language than Erlang, which only has stationary ports (in our
terminology). Chapter 5 will show how to program something similar to
process
linking in Oz.
---

Hmmm. Sounds good to me! Working my way inexorably to Chapter 5... :)

- Bob

> At the moment this makes the system largely unusable for any high
> availability type application.
> 
> sRp