[erlang-questions] Stopping a process with its supervision subtree

[Karolis Petrauskas]

Hello,

On Wed, Sep 14, 2016 at 8:20 PM, Dmitry Kolesnikov
<dmkolesnikov@REDACTED> wrote:
> Hello,
>
> This is a good question! I’d like to get other's opinion on the subject as well.
> I would go with following pattern:
>
> * S_X is {one_for_all, 0, 1} and all its child are permanent.
> * The process P_2 just {stop, normal, State} when the job is done.
>
> I do not like to “leak” a knowledge of supervisor to child processes. I’ll try to avoid usage of supervisor:terminate_child(…). On another hand, this pattern has disadvantage. You’ll see a “supervisor” S_X crash in the log when P_2 stops due to “permanent” property.
>
> The usage of simple_one_to_one supervisor seems to be right for this type of use-cases but it misses concept of related processes.
>
> What do you think?
>

Your note on the knowledge leak to the child process is right.
Sometimes I make child processes to know, how to start themselves
within its supervisor, e.g.

    -module(p).
    start_sup(X) -> p_sup:start_child(X).
    start_link(X) -> gen_server:start_link(...).

In this case, the process knows the supervisor anyway, so addition of
the call for stopping the process is not making things worse (at least
with knowledge leaking). Although I am not sure, if the process module
should have knowledge on the supervision tree, or it is better to
leave that knowledge to the caller/client process.

Your approach is interesting. I haven't considered it. I'm not sure,
if it would allow to differentiate between crashes of P_X (exits with
reason /= normal) and the normal termination. The same is for
differentiation between the main process (P_X) and its helper
processes). The false crash reports would make log analysis more
complicated: it would be not enough to find [error] to consider it
error. Admins wouldn't be happy about that.

>
> Best Regards,
> Dmitry
>
>

Karolis