> 
> It sounds like the shifting of a process from one machine to 
> another will
> involve what's also known as check-pointing - taking a 
> process, stoping it
> in its tracks, saving it off, reloading it (either on another 
> machine or
> on the same machine at a later time), and resuming it. Stopping and
> restarting the program isn't too hard. Getting all of the 
> file descriptors
> right (open files, open sockets) is hard.
> 

That's what I meant about proxying.  If process 'A' is moved
from Node 'orange' to Node 'apple' and once on node 'apple'
tries to do file I/O, this is where the proxy stuff fits in.

While on node 'apple', the modified syscall mechanism would
realize (from looking at the high order byte of the PID) that
the process was not started on node 'apple' but on node 'orange'.
So in order to make everything sane for the process, the syscall
is forwarded to node 'orange' for completion and returned back
to the process on node 'apple'.

That's what I meant.  The real problem is processes with 
semaphores open (or opened later) and shared memory or
message queues.  I suppose to handle this, the paging program
could be extended to swap pages from machine to machine.
But I suppose the ramifications of this are immense in 
terms of looking at memory a little differently and how
pages are mapped.


Bye



Andy


> Take care,
> 
> Bill
>