Add plugin support for alternative name lookup

OTP behaviour instances (gen_server, gen_fsm, gen_event) can currently
register themselves either locally or globally, and the behaviour
libraries (including gen.erl) support both addressing methods, as well
as the normal Pid and {Name, Node}.

However, there are alternative registry implementations - e.g. gproc -
and one can well imagine other ways of locating a behaviour instance,
e.g. on a node connected only via a TCP tunnel, rather than via
Distributed Erlang. In all these cases, one needs to write extra code
to identify the behaviour instance, even though the instance itself
need not be aware of how it is located.

This patch introduces a new way of locating a behaviour instance:
{via, Module, Name}.

Module is expected to export a subset of the functions in global.erl,
namely:

register_name(Name, Pid) -> yes | no
whereis_name(Name)  -> pid() | undefined
unregister_name(Name) -> ok
send(Name, Msg) -> Pid

Semantics are expected to be the same as for global.erl

This can be used in all places where {global, Name} is accepted.

faulty export in gen_fsm_SUITE.erl

await process death in dummy_via:reset()

fix error in gen_[server|fsm]:enter_loop()

fix documentation

1 files changed, 10 insertions, 2 deletions

diff --git a/lib/stdlib/doc/src/supervisor.xml b/lib/stdlib/doc/src/supervisor.xml
index cddb55e5c5..73df7183e6 100644
--- a/lib/stdlib/doc/src/supervisor.xml
+++ b/lib/stdlib/doc/src/supervisor.xml
@@ -271,8 +271,14 @@ child_spec() = {Id,StartFunc,Restart,Shutdown,Type,Modules}
         <p>If <c><anno>SupName</anno>={local,Name}</c> the supervisor is registered
           locally as <c>Name</c> using <c>register/2</c>. If
           <c><anno>SupName</anno>={global,Name}</c> the supervisor is registered
-          globally as <c>Name</c> using <c>global:register_name/2</c>.
-          If no name is provided, the supervisor is not registered.</p>
+          globally as <c>Name</c> using <c>global:register_name/2</c>. If
+          <c><anno>SupName</anno>={via,Module,Name}</c> the supervisor
+	  is registered as <c>Name</c> using the registry represented by
+	  <c>Module</c>. The <c>Module</c> callback should export the functions
+	  <c>register_name/2</c>, <c>unregister_name/1</c> and <c>send/2</c>,
+	  which should behave like the corresponding functions in <c>global</c>.
+	  Thus, <c>{via,global,Name}</c> is a valid reference.</p>
+          <p>If no name is provided, the supervisor is not registered.</p>
         <p><c><anno>Module</anno></c> is the name of the callback module.</p>
         <p><c><anno>Args</anno></c> is an arbitrary term which is passed as
           the argument to <c><anno>Module</anno>:init/1</c>.</p>
@@ -315,6 +321,8 @@ child_spec() = {Id,StartFunc,Restart,Shutdown,Type,Modules}
            registered at another node, or</item>
           <item><c>{global,Name}</c>, if the supervisor is globally
            registered.</item>
+          <item><c>{via,Module,Name}</c>, if the supervisor is registered
+	  through an alternative process registry.</item>
         </list>
         <p><c><anno>ChildSpec</anno></c> should be a valid child specification
           (unless the supervisor is a <c>simple_one_for_one</c>