Re: Poison

[oyvind.teig@xxxxxxx]

Home from vacation again.
In my paper for CPA-2001 I write this:

   ...
   Maybe this has to do with how occam processes are stopped, they do not
   stop when they go out of scope, they have stopped when they go out of
   scope (implicit "join"). We can not "kill" an occam process from the
   outside. We have to send it a message to have it exit. This message will
   only be accepted when the process is not engaged in some other activity.
   And after a process has been stopped, another user could legally try to
   communicate with it, the semantic is to wait forever. We have no
   null-pointer equivalent for an attempted pathological CHANnel
   communication. Also, we do not have a way to differentiate between
   normal waiting forever and pathological waiting forever.

Maybe the last sentence as a valid "problem statement" to what we are
talking about.

Yes, combinations of going out of scope and "mobile" channels seems like an
interesting place to start! A new occam should handle it automatically, not
a termination etc. pattern.

\ Øyvind /
/ Oyvind Teig - oyvind.teig@xxxxxxx
\ Kongsberg Maritime Ship Systems, Ship Control (KMSS-SC)
/ 7005 Trondheim Norway
\ 47 73581268 - http://www.kongsberg.com/eng/KM/
/ http://home.no.net/oyvteig/ - Home page