Hi Roberto!<div><br></div><div>Sorry for the very late answer - maybe you have already solved this and moved on... </div><div>Anyway - for the code swap to actually take effect, you must, as you suggest, do a fully qualified call to your loop - i.e. put ?MODULE in front of the call. This will make sure that after a new version of your module has been loaded, the next call to the loop function will execute the new code.</div>
<div><br></div><div>If you should use a timeout in your loop or not depends, I guess, on how often you get incoming TCP connections. You will experience problems if you happen to purge and load your module twice without the fully qualified call to the loop function being executed in between. The reason for this is that your process will be killed by the code server if it is still running old code at the time of your purge.</div>
<div><br></div><div>Example A - expected flow: </div><div>1) start your process with mod vsn 1 => vsn 1 is now 'current'. There is no 'old' code.</div><div>2) compile and load mod vsn 2 => vsn 2 is now 'current' and vsn 1 is 'old', but your process is still running vsn 1</div>
<div>3) force ?MODULE:loop in your process => your process now runs vsn 2, and vsn 1 is still 'old'</div><div>4) purge mod => vsn 1 is removed, your process still running vsn 2.</div><div>5) load mod vsn 3 => vsn 3 is now 'current' and vsn 2 is 'old'. process runs vsn 2.</div>
<div>etc...</div><div><br></div><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>Example B - forced purge which kills your process: </div><div>1) start your process with mod vsn 1 => vsn 1 is now 'current'. There is no 'old' code.</div>
<div>2) compile and load mod vsn 2 => vsn 2 is now 'current' and vsn 1 is 'old', but your process is still running vsn 1</div><div>3) purge mod (without doing a fully qualified function call first) => code_server tries to remove vsn 1, but since it is still running in your process, your process will be killed!!!</div>
<div>...</div><div><br></div><div>So - timing out the acceptor should be to prevent this type of problem...</div><div><br></div><div>Regarding system events: If you have your process hanging in a supervisor tree, you want to use the release_handler (or similar) for upgrading, and you might want to change the process state in any way during upgrade - then you should handle the change_code system event, i.e. implement the system_code_change callback.</div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br></div><div>I hope this was of some use...</div><div>Regards /siri</div><div><br></div></div><div><br><div class="gmail_quote">2011/11/30 Roberto Ostinelli <span dir="ltr"><<a href="mailto:roberto@widetag.com">roberto@widetag.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div>dear list,</div><div><br></div><div>i've got a process that has been started by a supervisor with proc_lib:spawn_link/3.</div>
<div><br></div><div>this process is mainly listening on new incoming TCP connections using gen_tcp:accept (or the SSL equivalent), with a timeout set to infinity. when a new connection gets requested, the acceptor process spawns a new process which will handle this new connection, and then it returns to listening for new connection requests.</div>

<div><br></div><div>what is the best way to ensure that the listening acceptor process gets updated on hot code swapping? do i just need to add a the ?MODULE macro in front of the calls that get back to the acceptor loop, i.e. ?MODULE:acceptor_loop? should i actually timeout the acceptor? is there any particular system event i should be catching?</div>

<div><br></div><div>any input warmly welcome.</div><div><br></div><div>thank you,</div><div><br></div><div>r.</div>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>