<br><br><div class="gmail_quote">2011/9/14 Henrik Nord <span dir="ltr"><<a href="mailto:henrik@erlang.org">henrik@erlang.org</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 09/08/2011 10:57 AM, Christopher Faulet wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
git fetch git://<a href="http://github.com/capflam/otp.git" target="_blank">github.com/capflam/otp.<u></u>git</a> supervisor_shutdown_infinity<br>
</blockquote></div>
I have included this branch in 'pu'<br>
<br>
Thank you for the contribution.<br>
<br>
No news about the other one as of yet<br>
<br>
Thank you for the contribution!<br><font color="#888888">
<br>
-- <br>
/Henrik Nord Erlang/OTP</font><div><div></div><div class="h5"><br>
<br>
______________________________<u></u>_________________<br>
erlang-patches mailing list<br>
<a href="mailto:erlang-patches@erlang.org" target="_blank">erlang-patches@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-patches" target="_blank">http://erlang.org/mailman/<u></u>listinfo/erlang-patches</a><br>
</div></div></blockquote></div><br><div><meta http-equiv="content-type" content="text/html; charset=utf-8">Hi again Christopher - thanks for the information!!<div><br></div><div>I have discussed the simple_one_for_one_shutdown problem with my colleagues, and finally we came to the same conclusion as you did :) The current behavior is definitely not acceptable so we decided to take in you patch. If you don't mind I would however like you to do some minor adjustments first:</div>
<div><br></div><div>1) I think it would be good to document the differences in how shutdown is handled for simple_one_for_one supervisors compared to other supervisors. I.e. that there is no defined shutdown order, and that the workers will terminate "in parallel".</div>
<div><br></div><div>2) If the shutdown strategy for the dynamic children is a timer, and the timer expires - then it looks like there will be one error report printed per worker that is not yet terminated (please correct me if I'm wrong). I believe that this could be quite heavy if there are many workers left. I would suggest to print only one error report in this situation - either listing all pids or just say how many processes we are talking about.</div>
<div><br></div><div><br></div><div><div>Also, as Henrik writes, your supervisor_shutdown_infinity patch is already included in pu. Before finally including it in our development branch, I would also like you to add some more information to the documentation (a warning?) - about using this feature with care, and if you need to use it then implement the worker in a safe way so the cleanup procedure can not hang... since this can actually cause the termination of the complete supervisor tree to hang.</div>
<div><br></div><div>Thanks!</div></div><div>/siri</div></div><div><br></div>