Supervisor child pid

[Roger Lipscombe]

On Wed, 4 Mar 2020 at 10:01, zxq9 <zxq9@REDACTED> wrote:
> It is very common in systems that I work on these days for a "service
> manager" sort of process to be a sibling of the simple_one_for_one that
> owns the workers in the service, and the service manager to have a few
> process registry-ish sort of functions.

I had a dig in the code, and discovered the justification for a custom
supervisor:

- We needed simple_one_for_one's "every child is the same" semantics.
- We needed one_for_one's find-or-start semantics (simple_one_for_one
ignores IDs).
- We did *not* want max-restarts; children restart infinitely. We
definitely did *not* want the supervisor killing itself.
- Default restart strategy is transient.

But (and I think this is an important distinction): while the
supervisor has find-or-start, i.e. uniqueness, we still need a
registry in order to *find* those processes from other places.

Other features of our registry: processes can have names and
properties; names are owned by a single process, but a process can
have multiple names; properties are many:many. Unlike gproc, which
already does a lot of that, we also had the need that registering a
name transferred it to the new process, rather than failing. I also,
at the time, found gproc's API overly confusing.

The supervisor and registry are not siblings (in the strict sense that
they have a common parent supervisor), but they're "siblings" in the
way that they're used. Another reason for our registry to not be a
strict sibling is that we also use it (in a different application)
paired with ranch.