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

[Ingela Andin]

Hi!

2016-09-19 11:14 GMT+02:00 Jachym Holecek <freza@REDACTED>:

> Hi,
>
> # Dmitry Kolesnikov 2016-09-14:
> > 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.
>
> Not knowing the full use case at hand I'll say that supervisors are
> generally used
> to manage the long-lived part of process hierarchy. It is a perfectly
> reasonable
> and common pattern to have a process manage its own children without
> supervisors,
> using just links and/or trap_exit and/or monitors. So when your
> "management" pro-
> cess terminates its auxiliary processes are shut down as well. That's why
> these
> primitives are built into the language after all.
>
>
Supervisors is not only useful for restarts, they are also useful for clean
process management. Used to gracefully stop applications making sure all
application processes indeed are closed.
Also if you do soft upgrade "by the book" the supervisors will be used to
suspend processes before performing the upgrade instructions.

I use monitors for processes that I need to interact with that are not part
of my application. Links are the primitives used to implement supervisors.



> Feel free to elaborate more precisely on what you're trying to do and why,
> in case
> the above doesn't seem helpful.
>
> > 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.
>
> I think simple_one_to_one supervisors are something of a historical
> mistake, their
> behaviour differes noticeably from the normal supervision strategies
> (enough so to
> come across as an inconsistency) and the functionality they offer is
> ridiculously
> easy to implement oneself in a way that exactly matches the use case at
> hand, not
> complicating things with unnecessary abstractions.
>
>

I do not think they are a mistake, I think they where a missed use case and
then added add hock, maybe without enough design considerations. Just
because it is easy, it does not
necessarily mean you should reinvent the wheel.

Regards Ingela Erlang/OTP team - Ericsson AB



> BR,
>         -- Jachym
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160920/862dc7ce/attachment.htm>