[erlang-questions] simple_one_for_one supervisor - what happens at restart? (also: gen_tcp)

[Chandru]

On 14 May 2016 at 09:28, Loïc Hoguin <essen@REDACTED> wrote:

> On 05/14/2016 09:46 AM, Chandru wrote:
>
>> On 14 May 2016 at 00:59, Ryan Stewart <zzantozz@REDACTED
>> <mailto:zzantozz@REDACTED>> wrote:
>>
>>     Oliver: there is no restart for children under a simple 1-1
>>     supervisor as documented under Supervision Principles at
>>     http://erlang.org/doc/man/supervisor.html#id243029
>>
>>     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 things
> dirty.


No, it's not. The reason a terminate callback is provided in a gen_server
is so that a process can clean up when it terminates, not to delegate it to
other processes.


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

No, it's not. From the manual:

The supervisor is responsible for starting, stopping and monitoring its
child processes. The basic idea of a supervisor is that it shall keep its
child processes alive by restarting them when necessary.


>
> Secondary functions of supervisors include restarting, reporting (with
> SASL) and upgrades. But they're entirely optional.
>

See above - what you state is secondary is its primary process. In fact,
making the process hierarchy discoverable is a secondary benefit of using a
supervisor.


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


Look carefully at the example I provided in the gist and Oliver's use case.
It is perfectly sound advice. If you are ever walking your supervisor
hierarchy do something with your application, you are doing it wrong.

Chandru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20160516/07e18408/attachment.htm>