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

Jachym Holecek <>
Mon Sep 19 11:14:26 CEST 2016


# 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.

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.

	-- Jachym

More information about the erlang-questions mailing list