
<html><head><meta http-equiv="Content-Type" content="text/html; charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi Jesper,<div class=""><br class=""></div><div class="">Thanks for your valuable notes. I see the point and agree. In a system with "real" supervision that is the model to be followed.</div><div class=""><br class=""></div><div class="">In our special case with one_for_one single layer supervision with all childs "temporary", as I see the supervisor does nothing but tracking the Ids, as when a child terminates for any reason it is not restarted, just removed from the child list of the supervisor. I feel it as a kind of registry with the advantage of having the Ids as a term() instead of atom() like the standard registry/2.</div><div class="">Moreover, if the spawned process makes an attempt to add itself to this supervisor, (and routes the reqest if supervisor:add_child returns with {error, {already_registered, {Pid}} ) performance can be pretty good as the supervisor process does not wait the "child" process to spin up with a possible long init function, blocking other childs to start.</div><div class=""><br class=""></div><div class="">In all other cases it seems to be a solution to be avoided, I agree.</div><div class=""><br class=""></div><div class="">Thanks all for your relevant thoughts, I learned a lot! Again.</div><div class=""><br class=""></div><div class="">Cheers</div><div class="">Zsolt<br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Mar 4, 2020, at 1:16 PM, Jesper Louis Andersen <<a href="mailto:jesper.louis.andersen@gmail.com" class="">jesper.louis.andersen@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><div dir="ltr" class=""><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif" class="">On Tue, Mar 3, 2020 at 8:51 PM Zsolt Laky <<a href="mailto:zsoci@lamardan.com" class="">zsoci@lamardan.com</a>> wrote:</span><br class=""></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Team,<br class="">

<br class="">

Finding a child Pid under a supervisor can be costly with the suggestion I found on the net with supervisor:which_children/1 as with a high number of children it returns a huge list with {Id, Child, Type, Modules} to find the MyChildId in.<br class="">

<br class=""></blockquote><div class=""><br class=""></div><div class=""><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Usually, I tend to keep the supervision domain separate from the communication domain. The reason is that supervision forms a tree and communication forms a hypergraph. That is, if you want to know the Pid of a process, you look it up in a registry, like gproc.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br class=""></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Mixing the life-time domain with the communication domain locks down your lifetime domain against changes. Also note that you can often cache Pids in processes depending on where they sit in a supervision tree. If you have a sibling in a one-for-all supervisor, you can rely on the sibling not changing Pid, as if it does, then you are getting terminated anyway. The same often happens if the Pid is sitting higher up the tree and you are sharing a common path. You can often rely on the fact that if it goes away, you are getting terminated very quickly.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br class=""></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">As an aside, this policy is somewhat the same you have in Go with its "context" package. a context.Context encodes when it is time for your goroutine to terminate, but it doesn't encode the actual policy of why you are terminating. This is generally good decoupling of concerns since you might want to use that goroutine in a different setting having a different policy. It is much the same I view supervision trees in Erlang: they encode policy separate from work, so the policy can change over time without the worker having to change.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br class=""></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">It *is* more work up front, but in the longer run, it tends to win you robustness, and also efficiency, which you have learned as well.</div><br class=""></div></div></div>

</div></blockquote></div><br class=""></div></body></html>