[erlang-questions] Pass Name to Dynamic Supervisors

[Garrett Smith]

As Magnus pointed out, registration is the responsibility of the
process, so a good place is in the init/1 function.

Lookup/queries however are from outside the process.

The way I look at this pattern is this:

- Keep processes as black box as possible
- To get information from a process, the process should publish it
where it can be read without involving the process

This pattern is common in OS apps (e.g. MySQL) where counters/stats
are maintained in a way that they can be read/queried efficiently by
external consumers, leaving the app to focus solely on its area of
concern.

On Sat, Sep 10, 2011 at 3:57 PM, Christopher Wilson <wilsoncj1@REDACTED> wrote:
> Thanks, that's pretty close.  How, or more importantly, when do I register
> the name.  Do I put this in the child worker/sup as part of the MFA used to
> spawn it or can this be called by the parent once start_child has been
> called?  Best practice is all I'm looking for.  Thanks again for pointing
> this one out.
> -Chris
>
> On Fri, Sep 9, 2011 at 1:03 PM, Garrett Smith <g@REDACTED> wrote:
>>
>> On Wed, Sep 7, 2011 at 9:09 PM, Christopher Wilson <wilsoncj1@REDACTED>
>> wrote:
>> > Is there a way to pass a name/ID into the call to
>> > supervisor:start_child,
>> > more specifically to init()?  I'd like to specify the name of the worker
>> > or
>> > supervisor such that when I ran supervisor:which_children I could
>> > identify
>> > what's what.
>> > Also, I've tried [unsuccessfully] to dynamically create a child spec and
>> > add
>> > pass that in.  Are there any decent examples out there on how to do this
>> > outside of the man pages?
>>
>> Take a look at:
>>
>> https://github.com/esl/gproc
>>
>> I'm not sure if that's the canonical repository -- maybe Ulf can weigh in.
>>
>> It's tempting, but I find it's best not to mess with the vanilla
>> supervisory facility and instead use gproc for getting a list of named
>> processes. You can also use gproc to publish interesting process stats
>> to consumers, thus avoiding costly and intrusive queries to the
>> processes themselves.
>>
>> This paper:
>>
>> https://github.com/esl/gproc/blob/master/doc/erlang07-wiger.pdf?raw=true
>>
>> provides the background for gproc and is otherwise an excellent read!
>>
>> You'll have a slight learning curve with gproc, but it's an
>> *indispensable* tool so well worth it.
>>
>> It needs to be in the core :)
>>
>> Garrett
>
>