[erlang-questions] Pass Name to Dynamic Supervisors
Mon Sep 12 02:21:17 CEST 2011
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
On Sat, Sep 10, 2011 at 3:57 PM, Christopher Wilson <> 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.
> On Fri, Sep 9, 2011 at 1:03 PM, Garrett Smith <> wrote:
>> On Wed, Sep 7, 2011 at 9:09 PM, Christopher Wilson <>
>> > 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:
>> 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:
>> 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 :)
More information about the erlang-questions