Supervisor child pid

[zxq9]

On 2020/03/04 18:22, Roger Lipscombe wrote:
> On Wed, 4 Mar 2020 at 08:33, zxq9 <zxq9@REDACTED> wrote:
>> 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.
> 
> fwiw, our current system has a custom supervisor implementation in one
> (and only one) place which deals specifically with "start a child with
> this ID; if it already exists, give me back the current pid"; it's a
> simplification/enhancement of a simple_one_for_one supervisor (which
> doesn't otherwise track IDs).
> 
> But, we *also* have a process registry tracking the same processes,
> but for different purposes. Whether I'd do that again in hindsight,
> I'm not sure; at the time we identified the need for a custom
> supervisor, and I *think* some of those constraints are still valid.
> Our process registry is also custom, because we had slightly different
> needs than most of the extant process registry implementations
> offered.

I can totally relate to this story!

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. These nearly always wind up 
doing quite a few extra things beyond just looking up a PID ("is A 
allowed to look B up? Does that cost a point?" etc.) and that pays off 
in the end because pure Name -> PID lookup isn't nearly as important 
having a proper abstraction for a service as an entity of its own.

In any case, there is usually a need for internal services to have the 
supervisor bits *and* service management bits, and this quite often 
results in implementation of some form of registry within the manager 
part (or glomming this together inside a custom supervisor). One of the 
most common design problems I see with folks new to architecture of 
concurrent systems is to fail to identify when they are writing an 
internal service and leave the responsibility for managing it *as* a 
service to functions that are either a) scattered through the system and 
have to do cheetah flips querying various components to build up enough 
state to make service-level management decisions or b) push everything 
into a God process that is supposed to know everything and winds up 
becoming a SPOF and SPBN at the same time.

-Craig