new syntax - a provocation

Luke Gorrie luke@REDACTED
Tue Sep 30 21:47:05 CEST 2003

"Pierpaolo BERNARDI" <bernardp@REDACTED> writes:

> > > > And also the question: why would you want to? Seriously.
> Because the node on which the process is running must be shut
> down for maintenance, upgraded, moved, load balanced,
> repainted, cloned ...

To smoothly fail over a whole node you would need to include a lot of
operating system state: sockets, open files, and so on. Perhaps this
is what AIX does when moving processes around in mainframes.

Another approach would be not depend on any such non-movable state -
e.g. if you are doing a 'pure' parallel computation. Perhaps this is
Kali's approach.

If your Erlang nodes are Unix processes on separate machines with lots
of open sockets and files - the typical case - then I don't think this
sort of transparent fail-over is realistic. But if your application is
fault-tolerant and will detect and recover from the sudden total
failure of a node/machine, then you've got a pretty good base-line to
handle these upgrade/move/new-paintjob situations methinks.

Back to the original point, I don't think that having a shared atom
heap within BEAM would be a serious obstacle in these situations :-)


(Note: Repainting our appliances any colour but green will void your

More information about the erlang-questions mailing list