at Jungerl: proc_reg, a flexible process registration utility
Ulf Wiger (AL/EAB)
Thu Jul 8 17:23:38 CEST 2004
> -----Original Message-----
> From: Luke Gorrie [mailto:lgorrie@REDACTED]On Behalf Of Luke
> Sent: den 8 juli 2004 17:01
> To: Ulf Wiger (AL/EAB)
> Cc: 'erlang-questions@REDACTED'
> Subject: Re: at Jungerl: proc_reg, a flexible process registration
> "Ulf Wiger (AL/EAB)" <ulf.wiger@REDACTED> writes:
> > I've written a small utility (an application) called
> proc_reg and committed it to Jungerl.
> > It allows for registration of (local) processes using any
> erlang term.
> > Furthermore, each process can register under several names.
> How're you using it?
I'm not, yet. (:
I just wrote it.
> This seems to have the potential for making programs more transparent
> at runtime, by using a lot more names instead of always PIDs. That
> could be really nice. Is that the intention? Any nice examples?
That's basically the intention.
One application I had in mind was (surprise) call control, where
you want to create a call ID, and then spawn a process that
handles the signaling and resource allocation for that call;
then, you would like to find this process based on the call ID.
The 'dispatcher' contrib was one way of solving this; it also
addressed the fact that you had a limited amount of processes,
but as this limit keeps rising -- currently > 200,000 processes,
this requirement becomes less interesting.
One might note that global does the same thing, but on a global
scale. Global also allows any term to be used as registered name,
and allows multiple names per process.
There are some differences, though:
- proc_reg is faster than global even if only one node is involved
(it's about 14x faster than global in the one-node case), but there's
no way to restrict global to local registration only if you have
multiple nodes, so then, the cost of registration will increase
rather substantially. A global registration facility based on
the 'locker' contrib ought to scale much better, but one doesn't
necessarily want globally registered names in all situations.
- If a registered process dies and is restarted, it cannot usually
call global:register_name/2 again, but must instead use
re_register_name/2. This is because global has not had time to
notice the previous crash. Proc_reg doesn't suffer from this
- Correspondingly, if a globally registered process is restarted,
and another process calls global:send/2, the message might be
addressed to the old process before global has a chance to
grasp what's happened. This cannot happen with proc_reg
(granted, the message can arrive in the message queue of a
process which then dies before handling the message, so one
is still not 100% safe...)
More information about the erlang-questions