RE: Poison

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

All
I'm trying to distinguish whether poison is cleaner, thought
of as a channel attribute, or a data attribute.  It seems that 
what you'd like is in the absence of special provisions, poison
propagates accross all connections. (Hmm. Maybe contagion might
be more descriptive?) This seems rather like NaN in the ieee
floating point standard.

On the other hand, processes can decide not to read channels, 
in which case the properties of the data lurking there are undiscovered.
Thats probably not what you want.  So it seems to me that it might be 
cleaner to think of it as a channel state that automatically affects
the run state of processes its connected to.  

No doubt you could express this (for the theoretical purists) as an 
implied par in every process that reads a "status channel" associated 
with each normal channel, and hence the same thing.  But, to me it seems 
easier to think of it as the status of a channel affecting the status
of connected processes.

Well that was my 2 cents. -jc

> -----Original Message-----
> From: P.H.Welch@xxxxxxxxx [mailto:P.H.Welch@xxxxxxxxx]
> Sent: Wednesday, July 18, 2001 11:45 AM
> To: tjoccam@xxxxxxxxxxxxx
> Cc: java-threads@xxxxxxxxx; occam-com@xxxxxxxxx
> Subject: Re: Poison
> 
> 
> 
> Hi Larry,
> 
> > 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).
> 
> Outputting POISON down a channel is the last thing a process does
> only if it has no other input or output channels.  If it does,
> if must send POISON down all its other outputs and wait to get
> POISON back on all its inputs (discarding anything else that
> arrives before that POISON).
> 
> All the above does go on in PARallel - so it's technically
> right that the actual component of the PAR sending the POISON
> does actually terminate after doing so.  But your advantage
> is to free the POISONing process' workspace automatically
> and the workspace of the POISONing component is tiny - it's
> not the workspace of the parent process.
> 
> However, in the case of a process with one output channel
> received always by an ALTing process, what you describe is
> pretty neat!
> 
> Peter.
>