Re: Poison

[Lawrence Dickson <tjoccam@xxxxxxxxxxxxx>]

Here's an interesting thing I came across at work, that
may or may not have relevance to "poison".

If an output is certainly going to an ALT input in its
communication partner, and it is the last act of its
process, a special "output-and-end-process" can be
used and the outputting process never rescheduled. This
works because the last act is always by the ALT input
side. Of course, the ALT input has to know not to 
reschedule its partner. 

The usefulness of this is that the ALT input side can
free the output side's workspace (in a mixed static and
dynamic memory allocation system I have). 

Larry Dickson

>From owner-occam-com-out@xxxxxxxxx Wed Jul 18 07:10:37 2001
From: M_Boosten <mboosten@xxxxxxxxxxxxxxxxxxx>
Date: Wed, 18 Jul 2001 16:03:19 +0200 (MEST)
To: java-threads@xxxxxxxxx, occam-com@xxxxxxxxx, P.H.Welch@xxxxxxxxx
Subject: Re: Poison
X-Sun-Charset: US-ASCII
Precedence: bulk

Peter,

> Marcel:
> > The aspect "termination sequence" is completely missing in the picture
> > right now.  How can the Graceful Termination strategy be mixed with
> > situation in which "termination sequences" are needed?
> > For example, a filesystem writes its cache to disk before a graceful
> > exit.  How is this supported by your Poison-based exit approach?

> When a process receives POISON or decides spontaenously to spread POISON,
> it should get itself into a safe state before doing anything.  If it were
> in the middle of some transaction with a server (or client) that requires
> more communications to complete, then it should do that - but not, of course,
> start up any more transactions.  For example, the filesystem should flush
> its buffers to the disk process before going into its graceful termination
> actions (which, of course, will send POISON to the disk).

> But finishing off such transactions is not strictly necessary - only polite.
> When you send POISON to your transaction partner, it will get the message
> that the current transaction is poisoned and should not commit to any state
> change caused by the transaction so far.  Of course, it might be *you* who
> is the partner that gets POISON in the middle of some transaction - in which
> case, you had better not continue with the transaction!

In other words, POISON is just a token that can at any time be sent via
any channel.  All processes have to be prepared to receive POISON at
any time, via any input channel.

Processes have to check that for getting poisoned regularly.  Processes that
need a termination sequence have to check for poiseness after each input.
This means that there is no parallel "Poison" distributing process, instead,
there is typically a Poison alternative in each ALT or IF statement to
guarantee the graceful shutdown.  Code that is not prepared for
POISON will not exit.

I expect that POISON will make the code more complex.  If the same lines of code
can be used, the POISON alternative should be checked for correctness explicitely.
POISON is nothing else than an extension to each existing protocol in an application.
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.

Is this the code for a POISON-supporting buffer?

  Buffer(in,out) =
    do {
       in?x;
       out!x;
    } while (x != POISON);

Do you need rules like:

     (c?x ; c?y) || (c!POISON; e)
   ==
     e

In other words, a POISONED channel keeps on sending an infinite amount
of POISENESS...  c?y finishes because c has been poisened...  I.e.,
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);

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

Do you need any additional POISON-specific rules at all?

Cheers,
	Marcel