Re: Poison

[P.H.Welch@xxxxxxxxx]

Marcel,

> In other words, POISON is just a token that can at any time be sent via
> any channel.  

No ...

> Or, maybe, I'm not allowed to perform input on a Poisened channel?

That's right.  The full rule is:

< POISON is just a token that can at any time be sent via any channel,
< but is the *last* thing ever sent down that channel.

So, POISON is only ever sent once down any channel - after which nothing.

> ............  All processes have to be prepared to receive POISON at
> any time, via any input channel.

Yes.  Unless you know for other (application specific) resons, you must
check *every* input to see if it's POISON :-( ...

> This means that there is no parallel "Poison" distributing process ...

Yes.  POISON is distributed by the application network alone using just
its application channels.  There is no need for anything else.

> POISON is nothing else than an extension to each existing protocol in
> an application.

Yes - it's an extension to every channel PROTOCOL.

> To introduce the POISON protocol on each channel, all application code needs
> to be checked such that a graceful exit will in fact occur as expected.

Yes.

> I expect that POISON will make the code more complex.

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?

> Is this the code for a POISON-supporting buffer?
> 
>   Buffer(in,out) =
>     do {
>        in?x;
>        out!x;
>     } while (x != POISON);

Yes.

> Do you need rules like:
> 
>      (c?x ; c?y) || (c!POISON; e)
>    ==
>      e

No.  The first line above is == to:

<      c?y || e

> In other words, a POISONED channel keeps on sending an infinite amount
> of POISENESS...  

No.  POISON is sent at most once, and as the last message, down any channel.
So, the answer to your next example:

> would the following Buffer process finish when I send it a single POISON
> via the "in" channel:
> 
>   Buffer(in,out) =
> 
>     do {
>        in?x;
>        out!x;
>        in?x;
>        out!x;
>     } while (x != POISON);

is no!  It is an incorrect unrolling of your earlier (correctly terminating)
buffer.

Peter.