[erlang-questions] runtime code upgrade, process ceases to exist.
Sverker Eriksson
sverker.eriksson@REDACTED
Thu Oct 1 18:29:01 CEST 2015
Your server function is not tail recursive.
You must do your call to ?MODULE:server()
tail recursive. Otherwise you leave a return address
referring to the old code on the call stack. And that is
why your process gets killed when the old code is purged.
/Sverker
On 10/01/2015 06:08 PM, Sid Muller wrote:
> Hi,
>
> I'm struggling to understand this runtime code upgrade oddity and was hoping someone could shed some light on this issue.
>
> The issue that I'm having is that the process running the latest code dies after the code is loaded with l(module) for the second time.
>
> I understand that only 2 versions of the software can be running at any given time but what I'm not understanding is why does the process with the latest code die or go away.
>
> I have process (a) that runs and calls b:do_stuff() which does stuff and responds back to (a).
>
> Module b has an upgrade function that will call into the latest module:
>
> upgrade()->
> Ref = make_ref(),
> ?SERVER ! {self(), Ref, upgrade},
> receive
> {Ref, ok} ->
> ok
> end.
>
> do_stuff()->
> Ref = make_ref(),
> ?SERVER ! {self(), Ref, do_stuff}, %% <-after second l(b) function fails here because ?SERVER is no longer registered, process is gone
> receive
> {Ref, ok} ->
> ok
> end.
>
> server()->
> receive
> {Client, Ref, upgrade} ->
> update_internal_structures(),
> Client ! {Ref, ok},
> ?MODULE:server();
> {Client, Ref, do_stuff} ->
> do_stuff(),
> Client ! {Ref, ok}
> end
> server().
>
>
> so after I load the new code with l(b). I call b:upgrade() from the shell and I can tell from the output in do_stuff() that new code is running when process a sends us do_stuff message. This is all fine until I make another change to module (b) but when I call l(b) process (b) is wiped out, gone, no more... It's not a crash in process (b), it just ceases to exist. And it's very frustrating because I have exactly the same code in another process which seems to survive multiple l(c) without any issues. The only difference between the two is that process(b) has a link to a dets process because it opens dets files and the link is created by the dets backend I believe.
>
> I must not be understanding this hot code upgrade....
>
> Can anyone shed any light on this?
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
More information about the erlang-questions
mailing list