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, 7 insertions, 0 deletions

diff --git a/lib/stdlib/doc/src/supervisor_bridge.xml b/lib/stdlib/doc/src/supervisor_bridge.xml
index c1a5e7947f..f6712d6c1d 100644
--- a/lib/stdlib/doc/src/supervisor_bridge.xml
+++ b/lib/stdlib/doc/src/supervisor_bridge.xml
@@ -63,6 +63,13 @@
           If <c><anno>SupBridgeName</anno>={global,<anno>Name</anno>}</c> the supervisor_bridge is
           registered globally as <c><anno>Name</anno></c> using
           <c>global:register_name/2</c>.
+          If <c><anno>SupBridgeName</anno>={via,<anno>Module</anno>,<anno>Name</anno>}</c> the supervisor_bridge is
+          registered as <c><anno>Name</anno></c> using a registry represented
+	  by <anno>Module</anno>. 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,GlobalName}</c> is a valid reference.
           If no name is provided, the supervisor_bridge is not registered.
           If there already exists a process with the specified
           <c><anno>SupBridgeName</anno></c> the function returns