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

[ianeast <ianeast@xxxxxxxxxxxxxxx>]

Hello Folks

I think we still suffer from thinking too much about context, rather than 
communication, and above-all commitment, ie protocol. Conventional OOP 
confuses context with communication from the beginning, and thus, in my 
view, stands no chance of expressing predictable concurrent behaviour. (I 
have completely lost interest in Java.)

Deadlock-freedom demands a higher layer of protocol - eg to implement 
some kind of client/server relation. Transmitting a channel will require 
the recipient to continue honouring such protocol. It must therefore also 
receive state information (history). This is where I begin to get stuck. 
One has to show that the design rules for client-server deadlock-freedom 
remain obeyed for _all possible_ configurations (client-server digraphs). 
(Each connection can lie at any state.) 

It's not too hard to see how one might express the ability of a process 
to accept such "typed" (?) channels, though one does wonder whether the 
extra language complexity is worth it, and whether the wonderful 
simplicity and readability of occam might vanish.

Transmitting a process might mean sending the _ability_ to honour a 
certain protocol. Things seem to get worse, as far as predictable 
behaviour is concerned. Any CS digraph is now possible.

I sometimes wonder how any software ever works! ...or perhaps it just 
seems to...

Ian

Dr. Ian Robert East         School of Computing and Mathematical Sciences
ireast@xxxxxxxxxxxxx                            Oxford Brookes University
(44) 1865 483635                                           Oxford OX3 0BP

Consultation hours for 2000/2001 Term 2
Not yet assigned