Suggestions for managing unregistered behaviors?

[David Michael]

In many of the tutorials I have read, including Programming Erlang and
Erlang Programming the primary example usages of gen_server, gen_fsm,
and others register the resulting process to a name, which presumably
is global in context of the Erlang node it is running on - effectively
making these gen_* singletons. Did I get this correct?

Can anyone help with how one might use hundreds or thousands of
gen_servers?

I have my own first pass and could include examples if needed.

Thanks
David

[Mihai Balea]

On Sep 11, 2009, at 3:23 PM, David Michael wrote:

>
> In many of the tutorials I have read, including Programming Erlang and
> Erlang Programming the primary example usages of gen_server, gen_fsm,
> and others register the resulting process to a name, which presumably
> is global in context of the Erlang node it is running on - effectively
> making these gen_* singletons. Did I get this correct?
>
> Can anyone help with how one might use hundreds or thousands of
> gen_servers?

Use start_link/3 to start up the gen_* process. By omitting the
ServerName parameter, you create an unregistered gen_* process, that
can later be referred to using its pid.

Mihai

[David Michael]

Nice, that is indeed what I am doing...
So then basically I just need to be in the business of passing around
these pids where necessary, or perhaps writing another function who
will know about this list of gen_*'s?

D

[Mihai Balea]

On Sep 11, 2009, at 3:48 PM, David Michael wrote:

>
> Nice, that is indeed what I am doing...
> So then basically I just need to be in the business of passing around
> these pids where necessary, or perhaps writing another function who
> will know about this list of gen_*'s?

The canonical way of handling them would be to use a supervisor. It is
not a requirement to use one, but there are advantages to doing so.
In the case of many (hundreds, thousands) identical gen_* processes,
use a simple_one_for_one supervisor.

And yes, the pid acts as an identifier and you will use it to call
your processes and send stuff to them.

Mihai

[David Michael]

Thanks Mihai,

Got it. So if I wanted to dynamically generate many gen_*'s, rather
than leaning on a list of ChildSpecs I would use something like
supervisor:start_child(Pid, [id1])

and remove them from supervision with ...
supervisor:delete_child(Sup, Id)
supervisor:terminate_child(Sup, Id)

I take it that a module in which I implement a supervisor behavior can
also have a number of functions for the creation and termination of
new processes so that these processes can be added and removed at
runtime....?

[Mihai Balea]

On Sep 11, 2009, at 5:12 PM, David Michael wrote:

>
> Thanks Mihai,
>
> Got it. So if I wanted to dynamically generate many gen_*'s, rather
> than leaning on a list of ChildSpecs I would use something like
> supervisor:start_child(Pid, [id1])
>
> and remove them from supervision with ...
> supervisor:delete_child(Sup, Id)
> supervisor:terminate_child(Sup, Id)
>
> I take it that a module in which I implement a supervisor behavior can
> also have a number of functions for the creation and termination of
> new processes so that these processes can be added and removed at
> runtime....?

In essence you're correct. However, the devil is in the details :)

You can terminate a child of a regular supervisor using
terminate_child and delete_child. However, the simple_one_for_one
supervisor does not allow that. In order to terminate a child of a
simple_one_for_one, you will need to message it to terminate itself or
terminate the whole supervisor and children tree. Why is this the
case? Beats me, but probably somebody on the erlang-questions mailing
list has a good answer :)

Mihai