<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 21, 2015 at 4:11 PM, Roger Lipscombe <span dir="ltr"><<a href="mailto:roger@differentpla.net" target="_blank">roger@differentpla.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":ly" class="a3s" style="overflow:hidden">I find myself writing a custom supervisor (because I need restarts to<br>
be delayed[1]), and I find myself wondering why OTP has a supervisor<br>
behaviour?<br></div></blockquote><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":ly" class="a3s" style="overflow:hidden">
That is: why does it require us to provide the Module:init/1 function?<br>
Surely we could just pass the restart strategy, child specs, etc. to<br>
supervisor:start_link directly?<br></div></blockquote></div><div class="gmail_extra"><br></div>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.<br><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">J.</div>
</div></div>