On Per-module process registration
Wed Feb 10 10:46:00 CET 2010
I found the pid_name EEP a bit confusing and I'm not sure that it solves
the problems that I have. Typically I will have a master gen_server
that works with a variable number of slave gen_servers each running
the code of the same module. The master wants to send a message to a
slave. It can't use a pid since the slave might die and be restarted
by its supervisor at any time. So I must synthesise an atom for a name
that looks something like '<scope>/<slave_id>' and put it into the node's
registry. I worry about the overhead of looking up such a name when the
registry has 100,000 processes in it.
I've thought that it would be nice if the supervisor could take care
of sending messages e.g. have supervisor:call_to(ChildID, Msg). The
supervisor then becomes the scope for the naming system. But that could
be awkward in a non-trivial supervisor tree.
Here's an in-between idea. Let's make a registry be a first class
object. It will function as a scope for a set of process names. The API
would look something like:
registry:spawn_link(Registry, Name, MFA)
registry:send_to(Registry, Name, MFA)
registry:call_to(Registry, Name, MFA)
registry:cast_to(Registry, Name, MFA)
The spawn function would be atomic wrt spawning and registration. The
master would create a registry for itself and spawn each slave within
its scope. We lose the nice Name!Msg syntax unless something like
(Registry, Name) ! Msg
[Registry, Name] ! Msg
The call_to and cast_to are for integration with gen_server et
al. Integration with a supervisor tree would take more thought. It might
require that the registry (a mutable object) be shared between servers
The distinction between a registry and a supervisor could be blurred by
giving the registry the ability to restart spawned processes that crash.
Maybe we could even have a hierarchy of registries with a process
being reached by a path through the registry tree.
Another issue is whether a registry could be accessed from more than
Anthony Shipman Mamas don't let your babies
als@REDACTED grow up to be outsourced.
More information about the erlang-questions