new syntax - a provocation
Mon Sep 29 23:32:41 CEST 2003
Luke Gorrie wrote:
>>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.
> And also the question: why would you want to? Seriously.
Code upgrading for a set of communicating nodes, for example.
(I haven't done this yet in Erlang, so the current methods may be
enough. OTOH I suspect that such an upgrade could make good use of some
automation, and that the Kali ideas are a step in the right direction.)
> Kali Scheme looks extremely complex and subtle to me. In Kali you can
> capture a process and send it to another machine, and it will
> magically transport the related code on-demand, do distributed garbage
> collection, and so on.
Transporting the related code is trivial (in the sense that you need no
rocket science to do that). Just patch up all calls to
not-yet-transported functions with a stub that loads the code from the
original location, for example - that's the lazy variant. Eagerly
transporting the code is even simpler.
> It even lazily copies the processes, sending
> just a few stack frames and copying the rest on-demand. This all
> strikes me as terrifying - what happens if something fails, when
> everything is so interconnected? I believe they assume that nothing
> will fail, which makes it a completely beast than Erlang.
You can do this all both lazily or eagerly. Both would have their place
even in Erlang - as a very fast-and-loose application, I'd copy
everything within an application eagerly and the connections between
applications lazily (because failure is an option there).
Anyway, I think Richard was more interested in code migration than in
lazy copying :-)
More information about the erlang-questions