Supervisor child pid

[zxq9]

On 2020/03/04 14:03, Zsolt Laky wrote:
> HI Craig,
> 
> 1. It is not necessary. I could use gproc as a registry for supervised proc_lib:spawned processes. Since supervisor itself has its registry, why should not I use that instead?

Because the meaning of a process in a system is more than its PID. 
Whatever part of the system knows the relevant meanings can be written 
in such a way that it *already* knows a map of meanings to PIDs.

It can take a bit of experience to identify the natural places for this, 
especially in a large system.

> 2. With thousands of medium lived processes (like session handling processes) I believe performance is important.

Performance is important, sure, but not because X set of PIDs happen to 
be children of supervisor Y. Simplicity tends to beat performance in 
most cases anyway.

Writing a system in such a way that there is a process that is 
responsible for the proper and sensible operation of a service within 
the system (whether it is session management, chat clients, game mob 
balance/spawning, stream routing, or whatever else) means that typically 
such a service manager is both the location where settings for the 
service reside and the place where the current status of the system is 
known ("The service is configured to only accept N client connections of 
type X at a given moment before closing the listen socket and reporting 
to a higher level manager" <- these sort of tasks).

If you need, for example, a way to route DMs in a chat system, the 
service manager itself is nearly always the simplest and fastest place 
to implement the lookup -- it knows a LOT more than the supervisor of 
the client connections ever could and quite often features of the system 
will evolve to the point that the additional service information or 
session meta will impact the *way* that the task that requires routing 
will function anyway.

Chat channels (or game zones or instances or whatever else needs to 
group a set of workers that means something inside the system but is 
arbitrary from the perspective of the supervisor) tend to be processes 
of their own and already know the PIDs of the member sessions being 
handled, and their enrolled lists are tiny fractions of a supervisor's 
set of children.

The only time where a list of just the PIDs is a meaningful piece of 
information is when some sort of system level service task is being 
performed, and these tend to be tasks that block, do not occur in a 
tight loop, and are not time sensitive.

Once a system (and the team or person writing it) evolves to the point 
that it is really addressing the problem to be solved in a natural way, 
the issue of looking up children of a given supervisor just doesn't come 
up. I remember several times when I *thought* I had this problem only to 
find that it just evaporated from the needs/tasks list the moment some 
other area of the system was restructured.

I now regard the feeling that "I need to look up the list of a 
supervisor's children" as a code smell in just about every case other 
than writing system tools.

-Craig