<div dir="ltr">Hi Fred,<div><br></div><div>Thanks for the excellent response.  This is very helpful and helped me understand exactly what it was I wanted to accomplish.  Which was slightly different in important ways from what I thought I was doing.  Thanks also for the fabulous book!</div>
<div><br></div><div>Cheers,</div><div>Rich</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Apr 30, 2014 at 1:12 PM, Fred Hebert <span dir="ltr"><<a href="mailto:mononcqc@ferd.ca" target="_blank">mononcqc@ferd.ca</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Answers inline<br>
<div class=""><br>
On 04/30, Youngkin, Rich wrote:<br>
> Hi,<br>
><br>
> I'm using a supervision tree to manage multiple sets of gen_servers.  I've<br>
> got a situation where gen_servers in one supervision tree (e.g., Tree-B)<br>
> are clients of gen_servers in another supervision tree (e.g., Tree-A).  I'd<br>
> like Tree-A and all of it's children to complete their initialization<br>
> processing before starting any of the children in Tree-B.<br>
><br>
</div>> [...]<br>
<div class="">><br>
> So given this diagram, A and its children 1,2 and 3 start and complete<br>
> initialization before B and children 4 and 5 are started and complete<br>
> initialization. Furthermore, initialization in this case means that in<br>
> module:init/1 the child casts itself a message to complete initialization.<br>
<br>
</div>I recommand in this case that Root Supervisor adopts a 'rest_for_one'<br>
strategy that will ensure that if Supervisor-A fails at any point during<br>
run-time, Supervisor-B and its children are killed before the whole<br>
structure is restarted. Otherwise, you may run into the issue of having<br>
Supervisor-B's children run without A being present.<br>
<div class=""><br>
<br>
> During Child 4's initialization it calls a function on Child 1 (which has<br>
> an init/1 implementation as described above).<br>
><br>
> In reading <a href="http://www.erlang.org/doc/man/supervisor.html#start_link-2" target="_blank">http://www.erlang.org/doc/man/supervisor.html#start_link-2</a> I<br>
> understand that Supervisor-A and all it's children will be started and<br>
> available before Supervisor-B and its children are started.  It's also my<br>
> understanding that when a child casts itself a message in its init/1<br>
> function that that message is guaranteed to be the first message in its<br>
> mailbox. Is my understanding of this correct and if so, is this a<br>
> reasonable way to do what I'm trying to accomplish?<br>
><br>
<br>
</div>Two things.<br>
<br>
1. The message is guaranteed to be the first one in the mailbox *iff*<br>
   the process hasn't been registered before, or given its pid to anyone<br>
   who could send it a message. Usually, that's fine when using OTP.<br>
2. The init scheme you're going for will turn your boot sequence into an<br>
   asynchronous one -- it's possible children of B will be spawned while<br>
   children of A are still doing the handling of the initial message in<br>
   their handle function.<br>
<br>
The latter may be a valid choice if the resource started asynchronously<br>
isn't always guaranteed to be available. Meaning that in this case,<br>
you're guaranteeing that the client will be up, but not the connection.<br>
<br>
This is actually a very sane model for external resources, but you just<br>
have to be aware you're implementing it :)<br>
<br>
See <a href="http://ferd.ca/it-s-about-the-guarantees.html" target="_blank">http://ferd.ca/it-s-about-the-guarantees.html</a> for more details on<br>
this.<br>
<br>
Regards,<br>
Fred.<br>
</blockquote></div><br></div>