[erlang-questions] supervisor:start_child

Martin Dimitrov mrtndimitrov@REDACTED
Mon May 2 20:30:39 CEST 2011


>
You can also "not register" them, either locally or globally. 
In your child's start_link, use the gen_server/3 instead of gen_server/4. 
  I do this but when using the same id for the specification, I receive already_started error. I believe both need to be unique but my question is why.  
  Regards,  
  Martin








 -------- Оригинално писмо --------

От: Mike Oxford moxford@REDACTED

Относно: Re: [erlang-questions] supervisor:start_child

До: Gregory Haskins  

Изпратено на: Понеделник, 2011, Май 2 21:25:57 EEST


You can also "not register" them, either locally or globally. 
In your child's start_link, use the gen_server/3 instead of gen_server/4. 
  You cannot do a "whereis(service)" type call, but your children will run and you won't get the conflicting IDs. 
 
  -mox

 On Mon, May 2, 2011 at 10:17 AM, Gregory Haskins   gregory.haskins@REDACTED >  wrote:
 
 On 5/2/11 12:38 PM, Martin Dimitrov wrote:

> Thanks for the advise about the interface.

>

>> A normal (i.e. not simple_on_for_one) supervisor allows you to stop,

> restart and delete children processes, so it needs a way to identify

> them. Hence the id.

>

> Isn't the process id the natural choice for these purposes?



 Its chicken and egg, though. 
The supervisor spawns the process and you

have to give it an ID to instruct it to start_child() in the first place.

 

>

> So there is no way to avoid the need of unique ids if using anything

> other than simple_one_for_one?



 When I don't care, I just use erlang:now() for the ID. 
Sloppy, perhaps,

but it gets the job done.



Kind Regards,

-Greg




_______________________________________________

erlang-questions mailing list

 erlang-questions@REDACTED 

 http://erlang.org/mailman/listinfo/erlang-questions 


  
 
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110502/3e9aa422/attachment.htm>


More information about the erlang-questions mailing list