[erlang-questions] non-trivial supervisor idioms?

[Essien Essien]

Hi Dan,

<snip>

> Thanks, I forgot about start phases.  Makes perfect sense for mnesia init.
>
> Now how about this scenario:  I am opening an ssh client connection which
> will have multiple channels.  The channel processes require a connection
> reference, so I have to establish the connection before creating them.  I
> will keep these channel processes under a supervisor.  Now, I have the
> choice of establishing the connection in supervisor init() and then
> returning  childspecs with the connection reference built-in, or creating a
> worker to establish the connection and then dynamically add channel
> processes to the supervisor afterwards.

I would create the connection in a connection object/process of some
sort and that process/object would be responsible for calling
supervisor:start_child(ChannelSup, [Connection]), when I needed a new
channel on that connection.

Roughly something like:

<code>

{ok, Connection} = connection:create(Host, Port, ...), % this would
create and return an SSH connection, a gen_server would do or
something.

{ok, ChanSup} = supervisor:start_link({local, chan_sup}, chan_sup_callback, []),

{ok, Chan1} = supervisor:start_child(ChanSup, [Connection]),
{ok, Chan2} = supervisor:start_child(ChanSup, [Connection]),
...

</code>


Ofcourse ChanSup is a simple_one_for_one supervisor with an init/1  like:

<code>

init([]) ->
      {ok, {
               {simple_one_for_one, 10, 10},
               [{channel,{channel, start_link, []},
                   transient, 5000, worker, [channel]}]}}.

</code>

I would also setup monitors b/w the Connection and the Channels, so if
the connection dies, say if its closed, the channels would all die
along with it. The connection's supervisor would be responsible for
bringing up this entire tree after disaster has struck.

>
> I have to think this kind of complex startup happens frequently enough that
> best practices have been established.  Or perhaps these situations are
> actually rare?

Dunno ;)

>
> BTW, my gut feeling is that I should leave supervisor init() alone and have
> a worker perform complex startup.

I don't really do much in my supervisor inits, sometimes in my top
level supervisors, I read config files, etc, but that's about it. Not
much more. That's me though... others more experienced than me may
have different ways of using supervisor:init/1

cheers,
Essien
>
> Thanks,
> Dan.
>