new syntax - a provocation
Richard A. O'Keefe
Fri Oct 3 05:02:19 CEST 2003
It's interesting to consider the question: "what would an Erlang
implementation have to be like for us to be able to take a running
process and move it to another processor?" (IBM's AIX was able to
do this on their mainframes, I believe. I think Kali Scheme can do it.
I should also have mentioned the University of Washington "Emerald"
Luke Gorrie <luke@REDACTED> asked:
And also the question: why would you want to? Seriously.
Surely the answer is obvious? To reduce *total* communication costs.
Suppose you have two processes X and Y, and two machines A and B.
Process X is running on A and Y is running on B.
Now process X discovers that it is going to communicate *lots* with
Y for a while. So X moves over the machine B, has a nice long chat with
Y, and then moves back to A.
Depending on exactly what the situation is, it may be possible for
X to spawn a process Z on B, send it some background information,
wait for Z to chat with Y, and then read Z's suicide note.
It's nice to have a single language mechanism (move process to node)
instead of relying on a different ad hoc solution for each of many
programs. Erlang shouldn't have any extra problem with moving code
over; if you are going to do spawn(M, F, [E1,...,En], Node) then you
had _better_ be perfectly sure what Node thinks M means anyway.
However, I wasn't suggesting that Erlang *SHOULD* be made to suppose
between-node process migration, only that it's worth *thinking* about
what it would take to do that.
More information about the erlang-questions