Re: Poison

[P.H.Welch@xxxxxxxxx]

Marcel et al,

Thanks to David Wood (who was able to make the appropriate unix incantation
to search through all my files looking for the word "Graceful"), I've found
my old "Graceful Termination - Graceful Resetting" paper from OUG-10 (1989).
I've placed .ps and .pdf versions on the following ftp site:

  ftp://ftp.cs.ukc.ac.uk/pub/phw/poison/

Your browser should be able to pick it up ...

> 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.

I'd talked about the terminating process tidying up on receipt of poison,
before spreading it, earlier somewhere in this discussion ... I think
something was briefly said about this in the original paper.

The "Graceful" referred to the ungracefulness of getting deadlocked when
you try to terminate a network incorrcetly - which mysteriously would
occasionally happen when we hacked this out specially for the network
and didn't know the trick!  It's also quite graceful the way the poison
(or rest signal) ripples across the network with no central control and
multiple riples can happen simultaenously with colliding waves cancelling
each other out ... pretty ... :) ...

> I think I would NOT introduce a general exception mechanism
> in Occam ...

I think I agree.  It really complicates the semantics.  Consider a WHILE
loop: the *only* way out is through failure of the WHILE-condition.  So,
immediately after the loop, we know why we are there - the WHILE-condition
is FALSE.  This is a powerful property, destroyed by GOTOs, BREAKs and
function RETURNs (occam has its replicated-IF for bounded linear searching,
which is the classic example quotes by those wanting a GOTO or BREAK).

An exception would also break you out of a loop ... that's the whole point!
But it does give you a complex loop semantics.

But if we're doing this in Java (JCSP/CTJ), then throwing a Poisoned exception
when interacting with a poisoned channel isn't going to make things any worse
than they already are ...

> 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.

Hey - that paper was 1989!  We only had 1-1 channels to worry about :).

But you're right ... we have to worry about them now ... and Barriers
and CREW-locks and ...

Gerald has a magic answer:

> Instead of poisoning processes via channels, processes could terminate
> (or interrupt) channels. If a process reads or writes on a terminated
> channel then a 'poison' exception is thrown and the try-catch clause
> catches the exception.

That solves the any-to-any channel problem *and* the problem of getting
at a pure-source process in the network - nice!  And we could poison any
synchronisation primitive the same way, I think?

> I'm wondering about terminating subsystems ...

The paper has a section on shutting down (or resetting) sub-systems ...

> Maybe there are more than just the two tokens: POISON and RESET.
> Maybe there is also POISON_KENT, and RESET_TWENTE, to avoid them to
> either poison or reset eachother via the java-threads mailing
> channel. :-)

... that might extend to provide that capability?

Weekend now!  Lots of still stuff to read!  Thanks to everyone for their
thoughts ... keep them coming ...

Peter.