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

RE: Mobile Processes (was 'Slides from my talk at CPA2000')



At 10:44 05/12/00 -0700, Campbell, John wrote:
What I'm struggling to understand is how you avoid the problems
attendant to aliasing if you transport an object with open
connections.  It seems to me that even if you manage to avoid
aliasing of the *object* you're going to get it on the open
*channels*.

I'm supposing that when you move the channel object (as opposed
to a conventional OO object) out of its original context, the
original context cannot communicate with it.  That's what I meant
by "sever its connections".


There has been a great deal of discussion here at Kent on these points - it's hard to keep the e-discussion up to date!

Firstly, consider a channel connection to a process to be like a reference to an object - if you have it, you can interact with the component.

One primary goal (THE primary goal?) of "The New Language I'm Working On" (working title!) is that, like occam, any inter-component dependencies are visible - they are channel connections. If the network diagram does not show a route from x to y, then x and y don't talk. That's very (very very) important for reasoning and maintenance.

The icarus idea of passing channel ends along other channels totally violates this. Suddenly, the only way to know who's talking to who, is to trace the run-time behavior of the whole system - just like OO. Further, the component hierarchy becomes meaningless - it's just as flat as OO (see slides). Further still, deadlock analysis (e.g. the client-server rules) can't be applied. David et al are well aware of this of course - this isn't "The Broken Promises of Icarus"!

So when a mobile process (or if you prefer, it's channels) moves along a channel, the sender looses all contact with that process. We are dividing the world of components into two camps - the static functional components, that are wired into networks and interact with many other components, and the mobile data components that move around freely, and have one user (client) at a time.

E.g. a compiler has a lexer, parser, checker and code-generator, which are wired together, and things like tokens, parse tree nodes, and code fragments move between them.

The choice between mobile and fixed is determined by the way you instantiate the component - it's not part of its declaration. A given component can be used in either role, and perhaps even change roles during it's lifetime.

Is there a way to limit access to
a sent object such that you don't get aliasing, but it can
still interact with its original environment?


If processes can change roles:
Mobile process x moves from env1 to env2. On arrival it plugs itself into a channel network that has connections back to env1 (and is no longer mobile).

So much more to say...

Tom.