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.<div><br></div><div>You cannot do a "whereis(service)" type call, but your children will run and you won't get the conflicting IDs.</div>
<div><br></div><div>-mox<br><br><div class="gmail_quote">On Mon, May 2, 2011 at 10:17 AM, Gregory Haskins <span dir="ltr"><<a href="mailto:gregory.haskins@gmail.com">gregory.haskins@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 5/2/11 12:38 PM, Martin Dimitrov wrote:<br>
> Thanks for the advise about the interface.<br>
><br>
>> A normal (i.e. not simple_on_for_one) supervisor allows you to stop,<br>
> restart and delete children processes, so it needs a way to identify<br>
> them. Hence the id.<br>
><br>
> Isn't the process id the natural choice for these purposes?<br>
<br>
</div>Its chicken and egg, though.  The supervisor spawns the process and you<br>
have to give it an ID to instruct it to start_child() in the first place.<br>
<div class="im"><br>
><br>
> So there is no way to avoid the need of unique ids if using anything<br>
> other than simple_one_for_one?<br>
<br>
</div>When I don't care, I just use erlang:now() for the ID.  Sloppy, perhaps,<br>
but it gets the job done.<br>
<br>
Kind Regards,<br>
-Greg<br>
<br>
<br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>