[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Poison



Marcel, this is nice stuff, isn't it? :)

I would suggest that 'poisoning channels' is exception-handling and
'poisoning processes' is termination-handling but not
exception-handling. 

For example, exception handling could perform graceful termination
(i.e., poisoning a process) or it could perform some sort of recovery
without termination, e.g., retrying communication. 

Poisoning processes and poisoning channels are two different concepts.
We need definitions to clarify both concepts.

'Poisoning channels' will be supported by CTJ in the next upcoming
revision.

David May once said in a discussion panel something like "It takes no
skills to add more functionality, but it takes skills to leave things
out which are not really necessary". Now that is what I call occam
philosophy :)  .... hmmm, this is also Java philosophy, hehe.

Cheers,
Gerald.

> -----Original Message-----
> From: M_Boosten [mailto:mboosten@xxxxxxxxxxxxxxxxxxx] 
> Sent: donderdag 26 juli 2001 10:09
> To: java-threads@xxxxxxxxx; occam-com@xxxxxxxxx
> Subject: Re: Poison
> 
> 
> Hi,
> 
> I just read Peter's paper on Graceful Termination.  The 
> distribution of this paper via the www has at least 
> gracefully terminated the discussion. :-)
> 
> Peter writes in the "Final Comments" that conclude on the 
> Graceful Termination and Resetting:
> 
>   "... is a REAL REQUIREMENT for MOST SYSTEMS that have to operate
>    in the REAL WORLD."
>    
> This is absolutely true.  Consequently, Graceful Termination 
> is of crucial importance to the acceptence of Java-CSP and 
> Occam based ideas to the real world.  If you can't provide 
> termination, you are a hardcore academic.
> 
> In my opinion, an important open issues is obtaining a solution.
> 
> I suggest:
> 
>    1. Implement A solution.
>       Is the exception-handling-based implementation of Graceful
>       Termination going to be implemented in the Java-based CSP
>       implementations?
>       Or something else?
>       Maybe try something in Occam?
> 
>    2. Investigate the practical consequences of the solution.
>       Aren't there better solutions?
>       How does this fit with industrial standards?
>       Expect some improvements, and implement it.
> 
> Cheers,
> 	Marcel
> 	
>