[erlang-questions] Supervision trees and child startup ordering

[Youngkin, Rich]

Hi Fred,

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!

Cheers,
Rich


On Wed, Apr 30, 2014 at 1:12 PM, Fred Hebert <mononcqc@REDACTED> wrote:

> Answers inline
>
> On 04/30, Youngkin, Rich wrote:
> > Hi,
> >
> > I'm using a supervision tree to manage multiple sets of gen_servers.
>  I've
> > got a situation where gen_servers in one supervision tree (e.g., Tree-B)
> > are clients of gen_servers in another supervision tree (e.g., Tree-A).
>  I'd
> > like Tree-A and all of it's children to complete their initialization
> > processing before starting any of the children in Tree-B.
> >
> > [...]
> >
> > So given this diagram, A and its children 1,2 and 3 start and complete
> > initialization before B and children 4 and 5 are started and complete
> > initialization. Furthermore, initialization in this case means that in
> > module:init/1 the child casts itself a message to complete
> initialization.
>
> I recommand in this case that Root Supervisor adopts a 'rest_for_one'
> strategy that will ensure that if Supervisor-A fails at any point during
> run-time, Supervisor-B and its children are killed before the whole
> structure is restarted. Otherwise, you may run into the issue of having
> Supervisor-B's children run without A being present.
>
>
> > During Child 4's initialization it calls a function on Child 1 (which has
> > an init/1 implementation as described above).
> >
> > In reading http://www.erlang.org/doc/man/supervisor.html#start_link-2 I
> > understand that Supervisor-A and all it's children will be started and
> > available before Supervisor-B and its children are started.  It's also my
> > understanding that when a child casts itself a message in its init/1
> > function that that message is guaranteed to be the first message in its
> > mailbox. Is my understanding of this correct and if so, is this a
> > reasonable way to do what I'm trying to accomplish?
> >
>
> Two things.
>
> 1. The message is guaranteed to be the first one in the mailbox *iff*
>    the process hasn't been registered before, or given its pid to anyone
>    who could send it a message. Usually, that's fine when using OTP.
> 2. The init scheme you're going for will turn your boot sequence into an
>    asynchronous one -- it's possible children of B will be spawned while
>    children of A are still doing the handling of the initial message in
>    their handle function.
>
> The latter may be a valid choice if the resource started asynchronously
> isn't always guaranteed to be available. Meaning that in this case,
> you're guaranteeing that the client will be up, but not the connection.
>
> This is actually a very sane model for external resources, but you just
> have to be aware you're implementing it :)
>
> See http://ferd.ca/it-s-about-the-guarantees.html for more details on
> this.
>
> Regards,
> Fred.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20140501/46972b1e/attachment.htm>