[erlang-questions] simple_one_for_one supervisor - what happens at restart? (also: gen_tcp)
Sat May 14 10:28:36 CEST 2016
On 05/14/2016 09:46 AM, Chandru wrote:
> On 14 May 2016 at 00:59, Ryan Stewart <
> <mailto:>> wrote:
> Oliver: there is no restart for children under a simple 1-1
> supervisor as documented under Supervision Principles at
> Otoh, I have to strongly disagree with Chandru about there being "no
> point" in supervising a connection process. Depending on the nature
> of your application, there can be a *huge* benefit in supervision,
> which is orderly shutdown. With a proper supervisory tree, you can
> ensure that all connection processes have a chance to finish their
> work and shut down cleanly when you stop your application.
> Cleanup can be done in the terminate callback if you use
> process_flag(trap_exit, true). You need to supervise a process primarily
> if you want it *restarted*, not for cleanup. Yes, you do have orderly
> shutdown mechanisms if the number of restarts exceed a "normal" value,
> but that is not the situation here.
This is bad advice. Cleanup should be done in a separate process,
otherwise sending a kill signal sent to the wrong process will leave
> Oliver has a server process to which clients connect. He does not need a
> supervisor for this because it is up to the client to reconnect if a
> connection is lost.
This is incorrect.
The primary function of supervisors is to provide a hierarchy of
processes belonging to an application. With such a hierarchy it becomes
possible to find and query information about any single process in your
system in a standard manner.
Secondary functions of supervisors include restarting, reporting (with
SASL) and upgrades. But they're entirely optional.
Having processes run without being attached to a supervisor is a big
mistake, because they either become invisible, or force you to implement
a non-standard way to find them. This makes introspecting a system more
complex than it should be.
The only acceptable use for non-supervised processes is to perform
asynchronous calls to functions. Those processes however should be
relatively short-lived, and you should really make sure that they can't
get stuck indefinitely.
Author of The Erlanger Playbook,
A book about software development using Erlang
More information about the erlang-questions