<div dir="ltr">Hi Magnus!<div><br></div><div>I've started looking at this, and I see that application_controller would need to handle much more than just load/unload requests in the blocking receive in order so solve this problem. There are quite a few calls in application_controller that have the timer set to infinity.</div><div><br></div><div>I'm not saying that this can/shall not be done, but I think we need to dig a bit deeper into the problem before we decide what to do. If it shall be fixed in the code or if better documentation might be sufficient.</div><div><br></div><div>You say that the problem was originally detected while starting the system and receiving an init:stop via user interaction. Would it be possible to provide some further details about this? Do you have applications that load/start/stop other applications?</div><div><br></div><div>Regards</div><div>/siri@otp</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-09-05 9:10 GMT+02:00 Magnus Ottenklinger <span dir="ltr"><<a href="mailto:magnus.ottenklinger@entelios.com" target="_blank">magnus.ottenklinger@entelios.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">





<div lang="DE" link="#0563C1" vlink="#954F72">
<div>
<p><span lang="EN-US">Hey List,<u></u><u></u></span></p>
<p><span lang="EN-US"><u></u> <u></u></span></p>
<p><span lang="EN-US">I sent  the following mail yesterday, but it seems that the mail was lost in space. Apologies if this reaches you twice.<u></u><u></u></span></p>
<p><span lang="EN-US"><u></u> <u></u></span></p>
<p><span lang="EN-US">Magnus<u></u><u></u></span></p>
<p><span lang="EN-US"><u></u> <u></u></span></p>
<p><span lang="EN-US">-----<u></u><u></u></span></p>
<p><span lang="EN-US"><u></u> <u></u></span></p>
<p><span lang="EN-US">We encountered a deadlock-problem with Erlang’s application mechanism in at least R16B01 and OTP 17. Namely, when using init:stop/0,1, a certain order of events can deadlock the application_controller, leaving the
 VM running. This can be mitigated using the Kernel application’s shutdown_timeout, but we think that this would just be a workaround and not a good fix.<u></u><u></u></span></p>
<p><span lang="EN-US"><u></u> <u></u></span></p>
<p><span lang="EN-US">Consider the following simple (and contrived) example:<u></u><u></u></span></p>
<p><span lang="EN-US"><u></u> <u></u></span></p>
<p><span lang="EN-US">-module(simple_app).<u></u><u></u></span></p>
<p><span lang="EN-US"><u></u> <u></u></span></p>
<p><span lang="EN-US">-behaviour(application).<u></u><u></u></span></p>
<p><span lang="EN-US"><u></u> <u></u></span></p>
<p><span lang="EN-US">-export([start/2,<u></u><u></u></span></p>
<p><span lang="EN-US">         stop/1]).<u></u><u></u></span></p>
<p><span lang="EN-US"><u></u> <u></u></span></p>
<p><span lang="EN-US">start(_Type=normal, _Args) -><u></u><u></u></span></p>
<p><span lang="EN-US">    {ok,self()}.<u></u><u></u></span></p>
<p><span lang="EN-US"><u></u> <u></u></span></p>
<p><span lang="EN-US">stop(_State) -><u></u><u></u></span></p>
<p><span lang="EN-US">    application:load(crypto), %% yes, this is a bad idea.<u></u><u></u></span></p>
<p><span lang="EN-US">    ok.<u></u><u></u></span></p>
<p><span lang="EN-US"><u></u> <u></u></span></p>
<p><span lang="EN-US">Compile and run the example:<u></u><u></u></span></p>
<p><span lang="EN-US"><u></u> <u></u></span></p>
<p><span lang="EN-US">1> make:all([load]).<u></u><u></u></span></p>
<p><span lang="EN-US">up_to_date<u></u><u></u></span></p>
<p><span lang="EN-US">2> application:start(simple).<u></u><u></u></span></p>
<p><span lang="EN-US">ok<u></u><u></u></span></p>
<p><span lang="EN-US">3> init:stop().<u></u><u></u></span></p>
<p><span lang="EN-US">ok<u></u><u></u></span></p>
<p><span lang="EN-US">4><u></u><u></u></span></p>
<p><span lang="EN-US"><u></u> <u></u></span></p>
<p><span lang="EN-US">After this, application_controller will wait for simple_app to shutdown, whereas simple_app waits for the application_controller. Calls like application:which_applications/0 will time out.<u></u><u></u></span></p>
<p><span lang="EN-US"><u></u> <u></u></span></p>
<p><span lang="EN-US">Note that we encountered the problem above in a more complicated setting: while starting our system, we received init:stop/0,1 from user interaction with the shell. As some processes were still starting up (and calling
 application:load/1 in that process), we got stuck in a VM which could not stop itself using init:stop/0,1 anymore.<u></u><u></u></span></p>
<p><span lang="EN-US"><u></u> <u></u></span></p>
<p><span lang="EN-US">I propose that application:load/1,2 (and probably application:unload/1,2 as well) should return {error,shutting_down} if the application_controller is currently shutting down. For this, the application_controller should
 be able to reply to application:load_application/1 within its blocking receive in application:terminate/2.<u></u><u></u></span></p>
<p><span lang="EN-US"><u></u> <u></u></span></p>
<p><span lang="EN-US">Of course, as mentioned above, using shutdown_timeout would be possible, but that might crash applications unnecessarily when they would be able to shutdown nicely.<u></u><u></u></span></p>
<p><span lang="EN-US"><u></u> <u></u></span></p>
<p><span lang="EN-US"><u></u> <u></u></span></p>
<p>Regards, Magnus<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
</div>
</div>

<br>_______________________________________________<br>
erlang-bugs mailing list<br>
<a href="mailto:erlang-bugs@erlang.org">erlang-bugs@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-bugs" target="_blank">http://erlang.org/mailman/listinfo/erlang-bugs</a><br>
<br></blockquote></div><br></div>