[erlang-questions] Designing supervision trees

[Scott Lystig Fritchie]

On Wed, May 5, 2010 at 6:01 AM, Alessandro Sivieri <alessandro...@REDACTED> wrote:
>> [...] but, for what I have understood from the supervisor
>> documentation, if I want a child to be supervised, it has to
>> implement one of the four behaviours, doesn't it? So, if my child
>> doesn't do that (it is simply a process which executes a single
>> function in loop), how can I attach it to a supervisor?

Garrett Smith <g@REDACTED> wrote:

gs> I haven't used this, but take a look at:

gs> http://erldocs.com/R13B04/stdlib/gen_server.html?search=gen_server&i=17#enter_loop/5

Garrett et al., there's an OTP stdlib module specifically for that kind
of situation, see 'supervisor_bridge'.  Not-compiled-or-tested code
follows:

    -module(my_bridge).
    -export([go_daddy/3, init/1, terminate/2]).

    go_daddy(A, B, C) ->
        supervisor_bridge:start_link(?MODULE, [A, B, C]).

    init(ArgList) ->
        Pid = proc_lib:spawn_link(not_otp_compliant, start_er_up, ArgList),
        {ok, Pid, Pid}.

    terminate(_Reason, Pid) ->
        exit(Pid, kill).
        %% Or perhaps send a message to pid asking it to stop?
        %% Whatever fits the need....

Stepping back to the general question of using supervisors, I recommend
a bit of experimentation.  It usually isn't *too* hard to modify your
supervisor hierarchy with a slightly different shape.  To mangle an
ancient proverb, "An experiment is worth a thousand words."

Oh, and make certain that the 'sasl' application is running so you get
some decent event logging when major processes are killed & restarted.

Then use the "Kill" button on the 'appmon' GUI to see what happens when
you kill certain processes.  Or use kill/2 to kill them, if the GUI
isn't convenient.  Then you'll see exactly how the supervisors react to
a failure just about anywhere in your hierarchy.

-Scott