Erlang supervisor termination behavior

I have what may be an unusual situation, an application that starts 2 top-level supervisors, eg,

...
-behavior(application).
...
start(_StartType, _StartArgs) ->
    sup1:start_link(),
    sup2:start_link().

They both have a {one_for_one, 0, 1} restart strategy. Their children implement a simple crash function that throws a bad_match error.

To my question, if I call sup1_child1:crash() supervisor sup1 will terminate but the application will keep running (ie, supervisor sup2 and its children are still available). If instead I call sup2_child1:crash() then the entire application terminates. This latter behavior is what I expect in both cases. If I flip the order of the start_link() calls, ie,

...
    sup2:start_link(),
    sup1:start_link().

then crashing sup1 will cause the application to terminate but crashing sup2 will not. So it appears the order in which start_link() is called determines which supervisor crash will cause the application to terminate. Is this expected? Or am I abusing the supervision tree capability by having 2 root supervisors?

Thanks,

Rich

---

It is entirely expected, and it is expected because you are abusing the supervision tree capability. There is a hidden supervisor called the "application supervisor". Your application:start function is supposed to return a SINGLE pid which is to be monitored by the application supervisor. If that process crashes, the BEAM VM will also crash (depending, actually, on how the application is started; similar to worker processes, your applications can be permanent or transient (maybe even temporary)).

You should have one top-level supervisor ( your application supervisor). If you need two supervisors at the top level, they should both be children of your application supervisor.

链接地址: http://www.djcxy.com/p/38212.html

上一篇: Erlang的主管与一个关键的孩子

下一篇: Erlang主管终止行为