<p dir="ltr">I have to mention that I think brutal_kill is a really bad choice for a default.</p>
<p dir="ltr">It breaks the expectation in Erlang that supervisors can never crash. An expectation that is in the core of what makes Erlang the great language that it is.</p>
<p dir="ltr">Dangling process trees are not fun to deal with (and don't happen on a VM crash).</p>
<p dir="ltr">To preserve the correctness and trust of supervision trees the default should be either infinity or depend on the child type.</p>
<p dir="ltr">For worker children brutal_kill is fine. For supervisor children infinity is the only sensible choice.</p>
<div class="gmail_quote">On Jul 1, 2014 7:06 AM, "Loïc Hoguin" <<a href="mailto:essen@ninenines.eu">essen@ninenines.eu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Just wanted to say I agree with everything José said, except 3. the different defaults for different process types. It makes things too hard to keep track of.<br>
<br>
I think brutal_kill is a great choice because it makes it easier for the user to stumble upon cold-start issues when restarting their application/release. The VM may crash so there's never a guarantee to run shutdown functions anyway, and too few people forget to test cases when these didn't run, leading to potential production disasters.<br>

<br>
On 06/30/2014 04:37 PM, José Valim wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have some feedback based on my experience in writing and teaching<br>
Erlang/Elixir.<br>
<br>
1. I would always require the supervision strategy. When I am<br>
prototyping, it is usually hard for me to reason about the intensity and<br>
restarts, but I can always reason about the supervision strategy. All<br>
teaching materials I know of also discuss the supervision right away, so<br>
having it explicit shouldn't hurt those cases.<br>
<br>
For such cases, maybe we should use the format of {{strategy(), map()},<br>
[children()]} (which is similar to what we have today).<br>
<br>
2. I also agree with Richard. Having a default of 0 restarts may cause<br>
confusion and forcing people to define them won't help when they still<br>
have no idea of what values they should use (because it is prototyping /<br>
early deploys). I usually fine tune those values based on the production<br>
system reports so having saner defaults, like Ulf's, may make more sense.<br>
<br>
3. The child_spec defaults are great and similar to the ones we use in<br>
Elixir with the only difference being the shutdown value. We have a<br>
default of 5000, which is the one usually recommended, but we set it to<br>
"infinity" if the type is a "supervisor" (which is the OTP docs<br>
recommendation if I remember correctly).<br>
<br>
Regarding 3., if the recommendation and the consensus in actual systems<br>
is to use brutal_kill for shutdown, I will gladly change Elixir to make<br>
it consistent with OTP defaults.<br>
<br>
Thanks for opening the changes for discussion!<br>
<br>
*José Valim*<br>
<a href="http://www.plataformatec.com.br" target="_blank">www.plataformatec.com.br</a> <<a href="http://www.plataformatec.com.br/" target="_blank">http://www.plataformatec.com.<u></u>br/</a>><br>
Skype: jv.ptec<br>
Founder and Lead Developer<br>
<br>
<br>
<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>
<br>
</blockquote>
<br>
-- <br>
Loïc Hoguin<br>
<a href="http://ninenines.eu" target="_blank">http://ninenines.eu</a><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>
</blockquote></div>