Supervisor child pid

[Zsolt Laky]

Hi Jesper,

Thanks for your valuable notes. I see the point and agree. In a system with "real" supervision that is the model to be followed.

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.
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.

In all other cases it seems to be a solution to be avoided, I agree.

Thanks all for your relevant thoughts, I learned a lot! Again.

Cheers
Zsolt

> On Mar 4, 2020, at 1:16 PM, Jesper Louis Andersen <jesper.louis.andersen@REDACTED> wrote:
> 
> On Tue, Mar 3, 2020 at 8:51 PM Zsolt Laky <zsoci@REDACTED <mailto:zsoci@REDACTED>> wrote:
> Dear Team,
> 
> 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.
> 
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200305/629f237e/attachment.htm>