<div dir="ltr">I think you're still ignoring the ordering guarantees of supervision. If "top_sup" supervises [important_server_process, "worker_sup"], and "worker_sup" is a simple_one_for_one where you keep your transient/temporary workers, then "top_sup" will ensure that important_server_process doesn't get the shutdown signal until all workers are finished. It may not apply in this specific case, but I've found it invaluable.</div><br><div class="gmail_quote"><div dir="ltr">On Tue, May 17, 2016 at 3:09 PM Chandru <<a href="mailto:chandrashekhar.mullaparthi@gmail.com">chandrashekhar.mullaparthi@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">On 17 May 2016 at 00:49, Fred Hebert <span dir="ltr"><<a href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</a>></span> wrote:<br></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>On 05/16, Chandru wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
No, it's not. The reason a terminate callback is provided in a gen_server<br>
is so that a process can clean up when it terminates, not to delegate it to<br>
other processes.<br>
<br>
</blockquote>
<br></span></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm gonna side with Loďc here. The terminate callback is good for any process-local cleanup or optimistic work, but is by no means a safe way to terminate anything.</blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
For example, if you have many children to terminate and through some interleaving brutall_kill is triggered (or anyone calls exit(Pid, kill)), whatever work you wanted to do in terminate will be skipped by a non-trappable exit signal.<br></blockquote></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote><div><br></div><div>Agreed, but how does adding the connection handling process (in Oliver's use case) to a simple_one_for_one supervisor help? It doesn't give him anything other than the illusion of being "supervised".</div></div></div></div><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div><br></div><div>Chandru</div><div><br></div></div></div></div>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org" target="_blank">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div>