[erlang-questions] Process migration/ Process state extraction/ injection
Daniel Dormont
dan@REDACTED
Wed Aug 1 03:42:29 CEST 2012
One of the first things I did in Erlang was implement node migration for a
certain type of Ejabberd process similar to the one below, but less general
and I entirely failed to implement message relaying. I had a few things
going for me:
- the process was a gen_fsm, so there was no mystery about how to obtain
its state at a given moment in time. In fact the module in question already
had handle_sync_event capable of setting or getting the state as a whole
(normally bad from a design standpoint I suppose, but it was helpful here)
- the process was created by a simple_one_for_one supervisor but had no
other links or monitors
- the process did not own any ports or ETS tables
- no other processes kept direct references to it. Messages sent to it were
immediately preceded by a Mnesia lookup to get its PID.
So all I had to do was spawn the process on the new node, push its gen_fsm
state, update the Mnesia table to point to the new PID, and kill the old
one. There was still a risk of losing messages; a relay would be the right
way to handle that I think.
Dan
On Tue, Jul 31, 2012 at 4:18 PM, Ali Sabil <ali.sabil@REDACTED> wrote:
> Hi Tyron,
>
> You could implement process migration yourself, I remember seeing
> something like that implemented in ejabberd:
>
> https://github.com/esl/ejabberd/blob/master/apps/ejabberd/src/p1_fsm.erl#L557
>
> The idea is to spawn another process in the remote node, and use a
> handover protocol to coordinate the migration.
>
> Best,
> Ali
>
> On Tue, Jul 31, 2012 at 8:21 PM, Tyron Zerafa <tyron.zerafa@REDACTED>
> wrote:
> > Hey again,
> > I am thinking that a weaker form of such mobility might suffice for
> my
> > project, but I am not sure. In this weaker form, it is enough to transfer
> > the code and execution can restart again. I need this primary to
> implement
> > the code-on-demand and remote-evaluation architectures. I do not believe
> > that this is so complex in Erlang, in fact if I remember correctly some
> > functionality already exists for such.
> >
> >
> > On Tue, Jul 31, 2012 at 8:15 PM, Gleb Peregud <gleber.p@REDACTED>
> wrote:
> >>
> >> On Tue, Jul 31, 2012 at 8:11 PM, Tyron Zerafa <tyron.zerafa@REDACTED>
> >> wrote:
> >> > Hey,
> >> > My primary intention is to implement strong mobility of processes.
> >> > Let's
> >> > say that process A is running on Node 1, I want to be able to suspend
> >> > this
> >> > process, transfer it to Node 2 and resume such process from where it
> >> > halted.
> >> > I believe that in order to achieve such I need to somehow preserve the
> >> > stack
> >> > trace, memory and other info.
> >>
> >> This task is non-trivial and will require a lot of work with ERTS and
> >> whole Erlang VM. Things you have to handle are:
> >> - stack
> >> - heap
> >> - binary refs
> >> - monitors
> >> - links
> >> - ets ownership
> >> - port ownership
> >> - messages sent to old process pid?
> >> - replacing old pid with new in other processes?
> >> - replacing old process with "replay" process?
> >>
> >> And I'm sure that those are not all details which will have to be
> handled.
> >>
> >> Cheers,
> >> Gleb
> >
> >
> >
> >
> > --
> > Best Regards,
> > Tyron Zerafa
> >
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
> >
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120731/966b52bf/attachment.htm>
More information about the erlang-questions
mailing list