For a classic approach to these problems, check out Gerry Popek's 
"LOCUS OS", MIT Press, ca. early to mid 80s. This was/is(?) a really 
comprehensive and beautiful distributed UNIX over multiple platforms 
with process migration and load balancing, etc.

Cheers,

Alan

-----

At 11:44 AM +0200 10/9/00, Johan Fabry wrote:
>Jeff Szuhay wrote:
>
>>  It occurred to me yesterday that as Squeak gets closer
>>  to being fully pluggable, some other issues arise:
>>
>>  1) imagine multiple VMs running each with their
>>  own image. How then would/could they communicate?
>
>Having multiple VM's talk to each other is a subject which hals been
>discussed at some length in a previous thread, so I suggest you have a
>look at the 'IPC and SRP' messages in, for example, the egroups archive
>(http://www.egroups.com/messagesearch/squeak?query=IPC%20and%20SRP).
>
>Saves us some typing ;-)
>
>>  2) imagine then these multiple VMs running/communicating
>>  but not necessarily on the same computer... distributed Squeak.
>
>Having some sort of distributed Squeak is one of the things I am toying
>with. A prerequisite here is some sort of higher-level interaction
>mechanism between different VM's (higher-level than simple socket
>communication) <plug> For example, you could try Remote Message Passing
>(http://prog.vub.ac.be/poolmembers/johanfabry/RMP.zip) </plug>
>
>But, you should keep in mind that the transition from multiple VM's on 1
>machine to multiple VM's on multiple machines adds the important factor
>of partial failures of the system. (A big problem in distributed
>systems!) For example: What do we do if one of the machines in the
>distributed system crashes?
>
>>  3) imagine one VM running but with multiple images running
>>  concurrently, or even remotely. The Squeak VM  along the l ines
>>  of a server app to multiple images.
>
>Having one VM running different images could be more efficient than
>multiple VM's, each running one image, but I doubt it would be worthwile
>to spend the energy on implementing this. Would it not be nicer to spend
>this energy on optimising the VM? This way everbody gains from it.
>
>>  4) imagen then multiple systems each with their own Squeak VM
>>  servers intercommunicating so that you have a real network OS.
>>  The SDNC: Squeak Distributed Network Computering.
>>  Multiple images being processed on multiple systems each inter-
>>  communicating... possibly even  transparent process sharing or
>>  load balancing through automatic process migration from VM to
>>  VM.
>>
>>  The last scenario seems to me to be the preferred one since it
>>  appears to me to be most efficient of system resources and would
>>  allow multiple minimal images to be executed, either on the same
>>  machine or remotely.
>
>You're touching on mobile agents here, where every agent (for sake of
>this discussion, let us define it as an object with its own thread) can
>migrate itself (the object's state and its thread) to another machine
>whenever it sees fit.
>
>The easiest way for the programmer to program these is the so-called
>'strong mobility': at any point of the agent's execution, the execution
>can be paused, the agent moved, and the execution unpaused (at the other
>host).
>
>To implement this, you must be able to reify both the object's state,
>and its execution stack. Luckily, the Smalltalk debugger does just that,
>so at least we know it is possible ... now we only need to adapt it.
>
>An interesting problem here is deciding *when* to migrate an agent, and
>*where* to migrate it to.
>
>Now imagine how you would write software for such a system ...
>
><plug>Anyway, all of this (and more) is what a number of people at the
>Programming Technology lab are thinking about/working on ...
>(http://prog.vub.ac.be/poolresearch/CBorg/index.htm)</plug>
>
>>  This also implies, to my little mind, that this would drive the VM
>>  further into the OS as one of its core services. I'm not to sure that
>>  tight VM integration with the kernel OS is either feasible or even
>>  possible on a wide scale.
>
>Not really, IMHO, you can still keep the VM as a separate 'layer' on top
>of the OS.
>
>--
>"You are more than the sum       Johan Fabry - Johan.Fabry at vub.ac.be
>  of what you consume.            Vrije Universiteit Brussel
>  Desire is not an occupation."   Programming Technology Lab, Room 10F709
>   -- KMFDM                       Pleinlaan 2, 1050 Brussels, Belgium