Re: Poison

[M_Boosten <mboosten@xxxxxxxxxxxxxxxxxxx>]

Peter,

> Marcel:
> > I expect that POISON will make the code more complex.
> [Peter wrote:]
> Not half!  That's why I asked my question: although the POISON solution is
> trivial (e.g. it can be mechanically retrofitted over an existing network),
> is there a better way?  Or should we just build a tool to do that retrofitting?

> In Java/JCSP/CTJ, a better way may be to use exceptions.  The channel read
> method could always look out for the POISON object being sent and, if spotted,
> throw an (unchecked) Poisoned exception.  That way, user process code that
> doesn't need to terminate is unchanged.  For those that do, the Poisoned
> exception handler code does not mess up the code operating the normal
> behaviour of the process - which is the whole point of exceptions.

> I think I like this.  It's a bit like Java's InterruptedException but,
> I think, cleaner - there's no mysterious Poisoned status to check
> (that can be changed behind the back of a thread by any other thread
> with a handle on it).  My caution is that occam doesn't have an exception
> mechanism for, maybe, good reasons.  I remember Geoff Barrett arguing
> about it when deigning occam3.  He chose not to go for it for, I think,
> semantic reasons ... are you there Geoff?

The main danger of a general exception mechanism is its
EXISTENCE.  Because it exists, people start using it, and in 95% of the
cases it is used for situations which, in fact, are non-exceptional, but
just another standard alternative.  In many cases, exception handling
makes it extremely difficult to write correct and readable code.

I think I would NOT introduce a general exception mechanism
in Occam; in stead, I would introduce a specific RESET or POISON
mechanism.  Such a mechanism is missing; I do not think there is a
need for a general exception mechanism.

In my opinion, the same holds for Java/JCSP/CTJ: the RESET or POISON
mechanism can nicely be implemented using exception handlers; however,
I would not advertise the use of the exception handling mechanism in
general.

A solution in JCSP/CTJ would be like:

     {
        ...normal code of the process...
     } catch(Poison(poisenedChannel)) {
        unpoisenedInputChannels = allInputChannels - poisenedChannel;     
        forAll (c : allOutputChannels) {
           c!POISON;
        }
        while (unpoisenedInputChannels != emptySet) {
           c = ALT(unpoisenedInputChannels);
           c?x;
           if (x == POISON) {
              unpoisenedInputChannels -= c;
           }
        }
        exit;
     }
     
You need some means to identify sets of input, output, and poisened
channels.  The normal code of the process does not even need to be
checked for Poison compatibility.

However, the result is a clear "kill -9", it is pretty much impossible
to place code in the exception handler that performs some more standard
communication to partner processes to achieve a stable state.  In general,
I think "Graceful Termination" sounds a bit too promissing, I think
simple "Termination" is much more graceful terminology.

Furthermore, I have been wondering about the many-to-one channel.  The
rule is probably: on reception of POISON via a N-to-one channel, one has
to wait for another N-1 POISON tokens during the graceful exit.

What about an N-toOneOf-M channel?
In fact, a N-toOneOf-M channel has got N+M users.  Each of them has to
indicate its non-interest in the channel.  Actually, then, you are building
a shared data release machanism using access counting...  there are definitely
strong similarities...

Cheers,
	Marcel