[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