[erlang-questions] supervisor:start_child
Martin Dimitrov
mrtndimitrov@REDACTED
Mon May 2 18:38:40 CEST 2011
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?
So there is no way to avoid the need of unique ids if using anything other than simple_one_for_one?
Regards,
Martin
-------- Оригинално писмо --------
От: Mihai Balea mihai@REDACTED
Относно: Re: [erlang-questions] supervisor:start_child
До: Martin Dimitrov
Изпратено на: Понеделник, 2011, Май 2 19:13:16 EEST
On May 2, 2011, at 8:32 AM, Martin Dimitrov wrote:
> Hi,
>
> I am developing a server that needs to spawn (under supervision) multiple child processes. Since these processes will be of different gen_server type, I cannot use simple_one_of_one restart strategy. These servers are anonymous, I refer to them by their Pids.
I think you might be able to use a simple one for one supervisor to start different types of gen_servers.
You would need to create an interface module to be used in the child spec, a module that would in turn call your various other gen_servers according to some parameters.
I've never done this, but I don't see why it wouldn't work.
>
> The problem I get is when I try to run 2 or more servers from the same type with the same id inside the child specification. I receive already_started error. By making the ids different, everything works fine.
>
> My question is why the id inside the child specification needs to be different for every process (even if it is of the same type)? What is the best practice to deal with this? Can the creation of dynamic ids be avoided?
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.
Mihai
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20110502/3ca58e3e/attachment.htm>
More information about the erlang-questions
mailing list