<div dir="ltr">On 14 May 2016 at 09:28, Loïc Hoguin <span dir="ltr"><<a href="mailto:essen@ninenines.eu" target="_blank">essen@ninenines.eu</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 05/14/2016 09:46 AM, Chandru wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
On 14 May 2016 at 00:59, Ryan Stewart <<a href="mailto:zzantozz@gmail.com" target="_blank">zzantozz@gmail.com</a><br></span><span class="">
<mailto:<a href="mailto:zzantozz@gmail.com" target="_blank">zzantozz@gmail.com</a>>> wrote:<br>
<br>
Oliver: there is no restart for children under a simple 1-1<br>
supervisor as documented under Supervision Principles at<br>
<a href="http://erlang.org/doc/man/supervisor.html#id243029" rel="noreferrer" target="_blank">http://erlang.org/doc/man/supervisor.html#id243029</a><br>
<br>
Otoh, I have to strongly disagree with Chandru about there being "no<br>
point" in supervising a connection process. Depending on the nature<br>
of your application, there can be a *huge* benefit in supervision,<br>
which is orderly shutdown. With a proper supervisory tree, you can<br>
ensure that all connection processes have a chance to finish their<br>
work and shut down cleanly when you stop your application.<br>
<br>
<br>
Cleanup can be done in the terminate callback if you use<br>
process_flag(trap_exit, true). You need to supervise a process primarily<br>
if you want it *restarted*, not for cleanup. Yes, you do have orderly<br>
shutdown mechanisms if the number of restarts exceed a "normal" value,<br>
but that is not the situation here.<br>
</span></blockquote>
<br>
This is bad advice. Cleanup should be done in a separate process, otherwise sending a kill signal sent to the wrong process will leave things dirty.</blockquote><div><br></div><div>No, it's not. The reason a terminate callback is provided in a gen_server is so that a process can clean up when it terminates, not to delegate it to other processes.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Oliver has a server process to which clients connect. He does not need a<br>
supervisor for this because it is up to the client to reconnect if a<br>
connection is lost.<br>
</blockquote>
<br></span>
This is incorrect.<br>
<br>
The primary function of supervisors is to provide a hierarchy of processes belonging to an application. With such a hierarchy it becomes possible to find and query information about any single process in your system in a standard manner.<br></blockquote><div><br></div><div>No, it's not. From the manual:</div><div><br></div><div><span style="color:rgb(0,0,0);font-family:Verdana,Arial,Helvetica,sans-serif;font-size:medium">The supervisor is responsible for starting, stopping and monitoring its child processes. The basic idea of a supervisor is that it shall keep its child processes alive by restarting them when necessary.</span></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Secondary functions of supervisors include restarting, reporting (with SASL) and upgrades. But they're entirely optional.<br></blockquote><div><br></div><div>See above - what you state is secondary is its primary process. In fact, making the process hierarchy discoverable is a secondary benefit of using a supervisor.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Having processes run without being attached to a supervisor is a big mistake, because they either become invisible, or force you to implement a non-standard way to find them. This makes introspecting a system more complex than it should be.</blockquote><div> </div><div>Look carefully at the example I provided in the gist and Oliver's use case. It is perfectly sound advice. If you are ever walking your supervisor hierarchy do something with your application, you are doing it wrong.</div><div><br></div><div>Chandru</div><div><br></div></div></div></div>