Process migration, was: Re: Extending arithmetic
Miguel Barreiro Paz
Wed Feb 12 18:10:37 CET 2003
> > vd> An image that popped up in my mind was that we could send a
> > vd> "freeze" command to a process and then be able to retrieve the
> > vd> process heap.
> > ETS tables muck up the works, <<...snip...>>
> Yes, all external references make this not work in the general case.
> Including external calls: is there a guarantee that there is a M:F(bla)
> in the new environment, and if yes, does it do the same thing?
Quite some time ago I worked on some process checkpointing /
migration support for plain unix processes, and the short story is: if you
want process migration, you want to develop on something like Erlang.
Todays more popular kind-of-transparent process migration system
seems to be Mosix. AFAIK all I/O in Mosix has to be done through the
process creation node (add a 2-way travel for all data, thus). Signals
present the same problems as messages in Erlang, so someone has to
remember "this process is no longer here, forward there". File handles
(with a shared filesystem) can be hacked to work through a
checkpoint&freeze/awake cycle, but in general with TCP sockets you can't
do that unless you use a scheme similar to Mosix. All sorts of other
problems with soft and hard state (ioctl's, fcntl's, etc formerly
performed to devices and files). All sorts of monsters awaiting around the
Transparent migration of unaware processes is an extremely cool,
hacker-attracting feature. I'm not sure if it's really useful, though, for
any practical use. It makes far more sense to plan for load balancing at
the application or middleware level. And it's not something one wants to
do at the OS level (at least if the OS is something like Unix or, heavens,
On the other hand, an Eddieware-like framework for easy and
standard development of clustered, load-balancing erlang services would be
What's the status of Eddie these days?
More information about the erlang-questions