<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">On Tue, Mar 3, 2020 at 8:51 PM Zsolt Laky <<a href="mailto:zsoci@lamardan.com">zsoci@lamardan.com</a>> wrote:</span><br></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>
<br>
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>
<br></blockquote><div><br></div><div><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></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></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></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></div></div></div>