new syntax - a provocation
Richard A. O'Keefe
Mon Oct 6 04:07:36 CEST 2003
Tony Rogvall <tony@REDACTED> wrote:
> The reason why "we" never did implement moving of processes was that
> it is not a "easy" in the general case.
I don't know who "we" is in this context, and I didn't ask that question
anyway. I know _that_ it isn't easy, and _why_ it isn't easy. What I
suggested was _thinking_about_what_it_would_take_. No more and no less.
Just _thinking_ about what it _would_ take. Not doing it.
> Just implementing the "move" is nearly trivial. Dump the
> stack/heap code and send it away, not the issue I think.
When you are running code that has been compiled to native code it is
_not_ at all trivial. In Erlang/OTP a process may point to shared
objects that do not live in its heap; that means simply copying the
process won't do. &c.
> 1. Normally when you want to move the process it is to late.
> system has crashed.
The reason I gave for moving a process has NOTHING to do with crashing.
It is a matter of reducing network costs, no more and no less. In fact,
The Emerald system, which I cited as a good example of a system that
does process migration, assumes a reliable network. One node goes down
and everything goes down. There are plenty of reasons for process migration
(load balancing, reducing transmission costs, access to localised resources)
which have absolutely nothing whatsoever to do with crashing in any way.
> 2. You may want to move before the crash, but then you want to
> move the resources with you i.e keep links / ports
> (files/sockets/drivers). Otherwise you need to restart all the
> resources on the new location.
Again, he seems to be under the impression that process migration has
something to do with crashing. It doesn't. Process migration is not
about crashing, ok?
> 3. Suppose 1 and 2 does not apply, we still want the process and keep
> the old identity. This means that some pid translation table must be
> implemented, notifications are sent to the systems connected to the
> system that hold the moved process.
You might want to keep the old identity. Then again, you might not.
It all depends. Having the same registration might do.
> If the process own some resources
> that we not want to move, then some proxy must be installed in place of
> the process moved to keep the resources running. etc etc etc.
Yes. And the systems which have implemented process migration *DO* that.
> Why not just have a gen_server, then you pass the state
> in a spawn call and let the application handle the problems with
> accessing/moving external resources. PROBLEM SOLVED.
PROBLEM NOT EVEN CLOSE TO ADDRESSED, LET ALONE SOLVED.
The problem is *not* to burden the application with all that stuff.
Evading a questino is not answering it!
It seems that I must stress again that I am _not_ recommending that Erlang
should turn into a clone of Emerald or KaliScheme or AIX, only that the
question "what would it take for Erlang to support something like that" is
one worth thinking about, because it leads to some interesting questions
and design ideas.
More information about the erlang-questions