Supervisor child pid

[Zsolt Laky]

We have somehow a similar situation as Roger.

The only reason of having the processes supervised in our case is to use release_handler for live upgrades. We had been having our own registry before starting to use supervisors and all "supervised" processes are "temporary" so they should not be restarted. The idea is, that if anyway we need to link our processes to a supervisor (for one specific reason), why shall we implement a separate registry for finding them?

I am greatfull for your thoughs, and enjoy consulting on a system design topic, nevertheless the original question is, whether the small code provided does what it was written for in a way that it does not break functionality of a one-to-one supervisor in this specific use case.

-spec lookup(Name) -> Result when
Name   :: term(),
Result :: {ok, pid()} | {error, not_registered}.
lookup(Name) ->
FakeChild = #{ id => Name,
              start => {?MODULE, ignore_start_child, []},
              restart => temporary,
              shutdown => 2000,
              type => worker,
              modules => dynamic},
case supervisor:start_child(my_sup, FakeChild) of
 {error, {already_started, Pid}} ->
   {ok, Pid};
 _Else -> %% {error, {ignored, _}}
   {error, not_registered}
end.

-spec ignore_start_child() ->
{error, ignored}.
ignore_start_child() ->
{error, ignored}.

Zsolt

> On Mar 4, 2020, at 10:22 AM, Roger Lipscombe <roger@REDACTED> 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.
> 
> -- 
> Roger.