RE: Poison

["Campbell, John" <John.Campbell@xxxxxxxxxxxxxx>]

Marcel and Peter
Let's get back to basics, for a moment, rather than argue the
merits of exception syntax.  The central issue is how do you manage
a network of large numbers of processes. Kill -9 is untennable if
you need to kill 23 nodes of a 48 node network.  Let alone getting it
right if have hundreds of nodes. 

What is the default behavior you want?  I think that if a process
has no coding to deal with poison, the behavior should be to propagate
the poison to all connected processes and expire.  If the process 
is coded to do something important before expiring, then so be it.

Now, how do you get behavior from a system without explicitely specifying
it?  It seems to me that you want every process to have an implicite process
paired with it and running in parrallel, the responsibility of which is to 
detect incomming poison, propagate it and terminate both.

Now, if you dont want the default behavior, you explicitly specify
the behavior of the poison watchdog (commissar?).
-jc

> -----Original Message-----
> From: M_Boosten [mailto:mboosten@xxxxxxxxxxxxxxxxxxx]
> Sent: Thursday, July 19, 2001 2:04 AM
> To: java-threads@xxxxxxxxx; occam-com@xxxxxxxxx; P.H.Welch@xxxxxxxxx
> Subject: Re: Poison
> 
> 
> 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
>