Mazen,<div><br></div><div>You can do the same thing with simple_one_for_one supervisors, one_for_all supervisors and one_for_one supervisors stacked in different levels. </div><div><br></div><div><br></div><div><br></div><div>
<br><br><div class="gmail_quote">On Fri, May 20, 2011 at 2:55 PM, Mazen Harake <span dir="ltr"><<a href="mailto:mazen.harake@gmail.com">mazen.harake@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
I don't agree with the "never" part. There are corner cases and I would, in general, absolutely agree with what you wrote but here is one example of an exception.<br><br>In my IRC library (<a href="https://github.com/mazenharake/eirc" target="_blank">https://github.com/mazenharake/eirc</a>) I have the following scenario:<br>
<br>One can create 1..n clients. Each client is a process (running a gen_server in eirc_cl.erl). A client can have many processes associated with it, in my case these are called Bots. Each bot is started and supervised by a client. A bot shall not terminate unless told to do so (gracefully) or if the parent dies (i.e the client). Now if I manually start a supervisor instance inside the gen_server I can simply make use of the supervisor functionality without handling any of that in my gen_server. I can add and remove children (bots) dynamically from my supervisor I.e. I don't have to maintain my own list of them and when I (the client) exits my children (I.e. the supervisor) will exit and thus my bots will exit... all according to OTP principals and I don't need to catch exit signals. This makes it REALLY easy to clean up things since all I have to do is to close the client process, the client process doesn't even need logic in the terminate callback since the children will exit with the same reason. If my supervisor was "on the outside" (like you suggest and which it normally is) I would have to make sure to clean up after myself with the supervisor.<br>
<br>So it is much simpler (from an isolation point of view) to (in my case) start a supervisor Inside the gen_server.<br><br>never say never ;)<br><font color="#888888"><br>/M</font><div><div></div><div class="h5"><br><br>
<br><br><br><div class="gmail_quote">On 18 May 2011 14:13, Vance Shipley <span dir="ltr"><<a href="mailto:vances@motivity.ca" target="_blank">vances@motivity.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Wed, May 18, 2011 at 11:38:50AM +0200, Roberto Ostinelli wrote:<br>
} just a quick question: can you think of any case in which starting a<br>
} supervisor from a gen_server would actually be a perfectly fit idea?<br>
<br>
</div>Never.<br>
<br>
+---------+<br>
| foo_sup |<br>
+-+-----+-+<br>
/ \<br>
+----------+--+ +--+---------+<br>
| bar_sup_sup | | foo_server |<br>
+---+---------+ +------------+<br>
|<br>
+----+----+<br>
| bar_sup |<br>
+---------+<br>
<br>
Start a supervisor for the new dynamic supervisor(s) and use<br>
supervisor:start_child/2 from the gen_server to start it.<br>
<br>
--<br>
<font color="#888888"> -Vance<br>
</font><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" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
</div></div></blockquote></div><br>
</div></div><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>