[erlang-questions] Freezing a process

[Raimo Niskanen]

On Sat, May 29, 2010 at 05:51:38AM +0200, Ulf Wiger wrote:
> On 05/29/2010 12:18 AM, Jeffrey Rennie (?????????) wrote:
> > 
> > In other light-weight concurrency solutions I've seen, such as
> > stackless Python, it's straight-forward to serialize processes.  I was
> > afraid I had overlooked something in Erlang.
> 
> In Termite (http://code.google.com/p/termite/), which is a Scheme
> dialect inspired by Erlang, it is also possible to migrate a
> process.
> 
> In Erlang, it isn't possible to do it in a generic way, and
> transparently. There are a few details that get in the way, such
> as that the owner of a port must be a local process, and ports
> are by design not possible to move transparently.
> 
> This is actually more or less an original design philosophy of
> Erlang. It was designed to support distribution transparency,
> such that it shouldn't matter where the other processes are,
> that are talking to you. At the same time, it had to be
> possible to be very explicit about where you spawn a process,
> since, if a process controls a hardware device, it should be
> running in a place where this is at all possible to do.
> 
> Another issue is that new failure conditions arise when
> crossing a node boundary (such as disrupted communication and
> partial failure), and it is sometimes necessary to take this
> into account in your program.
> 
> These things are not necessarily anathema to allowing the
> migration of processes. One could imagine a process flag
> forbidding the migration, for cases where the programmer
> thinks that code would break. But the OTP design philosophy
> is rather to move whole applications and being rather
> explicit about node boundaries, such that an OTP application
> instance always belongs to a specific node.
> 
> OTOH, if a process is designed to be easily movable, in that
> it has no tricky local dependencies, it is trivial to write
> a migrate() function for it. If it is a behaviour, the sys
> module provides the means to suspend a process, extract its
> state, and resume it. But in the case of migration, you would
> rather start the process in its new location with the
> migrated state, and e.g. use the gen_server:enter_loop()
> function to resume it.

Beware of the complication of links and monitors
since there is no mechanism to move a link nor a monitor.

A link could be moved by unlinking from the moving
process and then linking from the new moved process,
but if the other link end process has state that expects
a link to a certain pid() it will be surprised.

A monitor can not be moved since it is controlled
from the monitoring process. When your moving process
dies (I assume it will die after being moved), the
monitor will be triggered, and the monitoring process
will have to know there is a new process to monitor.

If, e.g, the moving process is a gen_Something, all clients
calling it will set up temporary monitors during the request
and that client code will be surprised if the gen_Something
disappears during a call...

> 
> BR,
> Ulf W
> ---------------------------------------------------
> 
> ---------------------------------------------------
> 
> WE'VE CHANGED NAMES!
> 
> Since January 1st 2010 Erlang Training and Consulting Ltd. has become ERLANG SOLUTIONS LTD.
> 
> www.erlang-solutions.com
> 
> 
> ________________________________________________________________
> erlang-questions (at) erlang.org mailing list.
> See http://www.erlang.org/faq.html
> To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED

-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB