<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div>Thanks all for your responses.</div><div><br></div><div>@Ingela, good point, hopefully I will be starting all the children dynamically at different times..</div><div><br></div><div>I have a bunch of packet decoders asking the supervisor to spawn a new child if needed (and they remembers the pid to some extend). Also I have a gen_server caching all the children {id, Pid} to avoid having to ask the supervisor the whole children list on every request.</div><div><br></div><div>I hope this will prevent me from hitting a hot spot on the supervisor for now.</div><div><br></div><div><br></div>Regards,<div><br><div apple-content-edited="true">
<div>Angel Alvarez</div><div>angeljalvarezmiguel at <a href="http://gmail.com">gmail.com</a></div><div><br></div><br class="Apple-interchange-newline">

</div>
<br><div><div>El 08/06/2014, a las 11:38, Ingela Andin <<a href="mailto:ingela.andin@gmail.com">ingela.andin@gmail.com</a>> escribió:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr"><br><div class="gmail_extra">Hi!<br><br><div class="gmail_quote">2014-06-06 22:31 GMT+02:00 Angel Alvarez (GMAIL) <span dir="ltr"><<a href="mailto:angeljalvarezmiguel@gmail.com" target="_blank">angeljalvarezmiguel@gmail.com</a>></span>:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Sorry I came across this, and I need to ask,<br>
<br>
<br>
I'm planning to have several thousand children (FSM machines  under the same supervisor.<br>
<br>
There is one FSM per client and they don't talk to each other so they are unrelated in this regard ..<br>
<br>
I thought "simple_one_one" is designed to cope with this, is it the right thing to do? or I'm missing something out?<br>
<br>
<br></blockquote><div><br></div><div>I think you are on the right track. However supervisors can need some further development in some places, and  it can be</div><div>desirable to start the processes without "init_ack-synchronisation" and then use gen_server/fsm:enter_loop. (The ssl application does this).</div>
<div>  </div><div>Regards Ingela Erlang/OTP team - Ericsson AB  </div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks in advance!<br>
<br>
Angel Alvarez (GMAIL)<br>
<a href="mailto:angeljalvarezmiguel@gmail.com" target="_blank">angeljalvarezmiguel@gmail.com</a><br>
<br>
<br>
<br>
El 30/05/2014, a las 15:02, Dmitry Kolesnikov <<a href="mailto:dmkolesnikov@gmail.com" target="_blank">dmkolesnikov@gmail.com</a>> escribió:<br>
<div><br>
> I’ll be trivial to say that design of supervisor tree is an application specific.<br>
><br>
> One lesson learned is that supervision it’s about the guarantees. Take a look into Fred’s post<br>
> <a href="http://ferd.ca/it-s-about-the-guarantees.html" target="_blank">http://ferd.ca/it-s-about-the-guarantees.html</a><br>
><br>
> Personally, I’am splitting an application to smaller functional units with own supervisors per unit.<br>
> If an unit design needs 15 children then I see no issue to have them.<br>
> However, if 15 children do not have any relations each other then I am combining them to guaranty deterministic application state after failure.<br>
><br>
> Best Regards,<br>
> Dmitry<br>
><br>
> On 30 May 2014, at 14:28, Roger Lipscombe <<a href="mailto:roger@differentpla.net" target="_blank">roger@differentpla.net</a>> wrote:<br>
><br>
>> I'm concerned that the top-level supervisor in one of our applications<br>
>> has too many children. It has about 15 children, which are only<br>
>> vaguely related to each other.<br>
>><br>
>> What's a good rule-of-thumb for whether a supervisor tree is too wide?<br>
>> Or too deep? Or am I thinking on the wrong level here?<br>
>><br>
>> Thanks,<br>
>> Roger.<br>
>> _______________________________________________<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>
><br>
> _______________________________________________<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>
<br>
_______________________________________________<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></blockquote></div><br></div></div>
</blockquote></div><br></div></body></html>