Supervisor child pid

[Jesper Louis Andersen]

On Tue, Mar 3, 2020 at 8:51 PM Zsolt Laky <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/20200304/0ef5a598/attachment.htm>