Re: Poison

[M_Boosten <mboosten@xxxxxxxxxxxxxxxxxxx>]

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