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

[Tom Locke <tsl2@xxxxxxxxx>]

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.