erlang-questions] On Per-module process registration
Wed Feb 10 11:47:59 CET 2010
I'm not sure I understand either your requirement or the motivation for
it, but perhaps the Global Name Registration Facility (global module)
It's probably pretty fast even for the single-node case, and appears to
have been acceptably optimized for multiple nodes.
I only use global:trans/2, and I use that only to serialize access to the
regular process registry, which doesn't have anything analogous from
what I can see. 'Node' is the only sort of scope concept the global
module seems to support; I suppose you could make use of it (logically,
anyway) even on a single physical node by running more instances of
Erlang as logical nodes.
The documentation for the global module is wordy but also a little
ambiguous and skimpy on some details (don't you just hate that
combination?). It's on my list of chapters to clean up.
On 2/10/2010, "Anthony Shipman" <> wrote:
>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
> grow up to be outsourced.
>erlang-questions (at) erlang.org mailing list.
>To unsubscribe; mailto:
More information about the erlang-questions