[erlang-questions] Pass Name to Dynamic Supervisors

Magnus Klaar <>
Sun Sep 11 16:49:50 CEST 2011


Hi!

If you are using gproc you are expected to register the name of a process
from the same process. I've never found a reason to do this the other way
around. A registered name is a property of the child process/module and
therefore it should be responsible for this.

We are using gproc in etorrent, if you grep the source code for register it
should give you some usage examples.

MVH Magnus Klaar

On Sat, Sep 10, 2011 at 10: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.
>
> -Chris
>
>
> On Fri, Sep 9, 2011 at 1:03 PM, Garrett Smith <> wrote:
>
>> On Wed, Sep 7, 2011 at 9:09 PM, Christopher Wilson <>
>> 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
>>
>
>
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110911/ee539c1d/attachment.html>


More information about the erlang-questions mailing list