[erlang-questions] Why have a supervisor behaviour?

[Roger Lipscombe]

On 21 May 2015 at 15:23, Jesper Louis Andersen
<jesper.louis.andersen@REDACTED> wrote:
> Another way around this is to let the supervisor just start the server and
> then let the server itself handle the delay by querying a delay_manager, or
> something such.

I considered that, but I have a small wrinkle: I need find_or_start
semantics, such that if the child is already started, it's returned;
if the child doesn't exist, it's started and returned (so far this is
just one_for_one, ish); but -- if it's in the sin bin -- it needs to
be restarted immediately. The caller _needs_ a valid pid. Having a
delay_manager might complicate that?

>> That is: why does it require us to provide the Module:init/1 function?
>> Surely we could just pass the restart strategy, child specs, etc. to
>> supervisor:start_link directly?
>
> Because init/1 runs in the context of the supervisor process, not the
> invoker of start_link/1. If you create an ETS table in the supervisor, for
> instance, its protection is relative to who created it. And so is its
> lifetime. You can't easily do that if you pass in the data in start_link/1,
> since you would have to pass a fun anyway.

But the supervisor's not supposed to _do_ anything, right? It only has
Mod:init. If you want an ETS table, you should have it owned by the
supervisor's first child, right?

Cheers,
Roger.