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

[Chandru]

On 22 May 2016 at 00:25, Ryan Stewart <zzantozz@REDACTED> wrote:

> I think you're still ignoring the ordering guarantees of supervision. If
> "top_sup" supervises [important_server_process, "worker_sup"], and
> "worker_sup" is a simple_one_for_one where you keep your
> transient/temporary workers, then "top_sup" will ensure that
> important_server_process doesn't get the shutdown signal until all workers
> are finished. It may not apply in this specific case, but I've found it
> invaluable.
>

Sure, it is useful, but I was discussing Oliver's specific question for his
use case. Not the general merits of supervision trees.

Chandru


> On Tue, May 17, 2016 at 3:09 PM Chandru <
> chandrashekhar.mullaparthi@REDACTED> wrote:
>
>> On 17 May 2016 at 00:49, Fred Hebert <mononcqc@REDACTED> wrote:
>>
>>> On 05/16, Chandru wrote:
>>>
>>>>
>>>> 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.
>>>>
>>>>
>>> I'm gonna side with Loďc here. The terminate callback is good for any
>>> process-local cleanup or optimistic work, but is by no means a safe way to
>>> terminate anything.
>>
>>
>>>
>>> For example, if you have many children to terminate and through some
>>> interleaving brutall_kill is triggered (or anyone calls exit(Pid, kill)),
>>> whatever work you wanted to do in terminate will be skipped by a
>>> non-trappable exit signal.
>>>
>>
>> Agreed, but how does adding the connection handling process (in Oliver's
>> use case) to a simple_one_for_one supervisor help? It doesn't give him
>> anything other than the illusion of being "supervised".
>>
>> Chandru
>>
>> _______________________________________________
>> 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/20160522/4ac36674/attachment.htm>