<div dir="ltr">Hi!<br><div><div class="gmail_extra"><br><div class="gmail_quote">2016-09-19 11:14 GMT+02:00 Jachym Holecek <span dir="ltr"><<a target="_blank" href="mailto:freza@circlewave.net">freza@circlewave.net</a>></span>:<br><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">Hi,<br>
<br>
# Dmitry Kolesnikov 2016-09-14:<br>
> This is a good question! I?d like to get other's opinion on the subject as well.<br>
<span class="gmail-">> I would go with following pattern:<br>
><br>
> * S_X is {one_for_all, 0, 1} and all its child are permanent.<br>
> * The process P_2 just {stop, normal, State} when the job is done.<br>
><br>
</span>> I do not like to ?leak? a knowledge of supervisor to child processes. I?ll try to<br>
> avoid usage of supervisor:terminate_child(?). On another hand, this pattern has<br>
> disadvantage. You?ll see a ?supervisor? S_X crash in the log when P_2 stops due to<br>
> ?permanent? property.<br>
<br>
Not knowing the full use case at hand I'll say that supervisors are generally used<br>
to manage the long-lived part of process hierarchy. It is a perfectly reasonable<br>
and common pattern to have a process manage its own children without supervisors,<br>
using just links and/or trap_exit and/or monitors. So when your "management" pro-<br>
cess terminates its auxiliary processes are shut down as well. That's why these<br>
primitives are built into the language after all.<br>
<br></blockquote><div><br><div>Supervisors is not only useful for restarts, they are also useful for clean process management. Used to gracefully stop applications making sure all application processes indeed are closed.<br></div><div>Also
 if you do soft upgrade "by the book" the supervisors will be used to 
suspend processes before performing the upgrade instructions. <br><br></div>I
 use monitors for processes that I need to interact with that 
are not part of my application. Links are the primitives used to 
implement supervisors.<br><br> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
Feel free to elaborate more precisely on what you're trying to do and why, in case<br>
the above doesn't seem helpful.<br>
<span class="gmail-"><br></span></blockquote><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><span class="gmail-">
> The usage of simple_one_to_one supervisor seems to be right for this type of<br>
> use-cases but it misses concept of related processes.<br>
<br>
</span>I think simple_one_to_one supervisors are something of a historical mistake, their<br>
behaviour differes noticeably from the normal supervision strategies (enough so to<br>
come across as an inconsistency) and the functionality they offer is ridiculously<br>
easy to implement oneself in a way that exactly matches the use case at hand, not<br>
complicating things with unnecessary abstractions.<br>
<br></blockquote><div><br><br></div><div>I do not think they are a mistake, I think they where a missed use case and then added add hock, maybe without enough design considerations. Just because it is easy, it does not<br></div><div>necessarily mean you should reinvent the wheel. <br></div><div> <br></div><div>Regards Ingela Erlang/OTP team - Ericsson AB<br></div><div><br> </div><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote">
BR,<br>
        -- Jachym<br>
<div class="gmail-HOEnZb"><div class="gmail-h5">______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a target="_blank" rel="noreferrer" href="http://erlang.org/mailman/listinfo/erlang-questions">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br></div></div></div>