erlang-questions] On Per-module process registration

[Michael Turner]

Anthony,

I'm not sure I understand either your requirement or the motivation for
it, but perhaps the Global Name Registration Facility (global module)
could help?

  http://www.erlang.org/doc/man/global.html

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.

-michael turner

On 2/10/2010, "Anthony Shipman" <als@REDACTED> 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:new()
>    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
>    or
>	[Registry, Name] ! Msg
>is defined.
>
>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
>and supervisors.
>
>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
>one node.
>
>--
>Anthony Shipman                    Mamas don't let your babies
>als@REDACTED                   grow up to be outsourced.
>
>________________________________________________________________
>erlang-questions (at) erlang.org mailing list.
>See http://www.erlang.org/faq.html
>To unsubscribe; mailto:erlang-questions-unsubscribe@REDACTED
>
>