at Jungerl: proc_reg, a flexible process registration utility

[Ulf Wiger (AL/EAB)]

> -----Original Message-----
> From: Luke Gorrie [mailto:lgorrie@REDACTED]On Behalf Of Luke
> Gorrie
> 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
> utility
> 
> 
> "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 
  problem.

- 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...)

/Uffe