[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
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