[erlang-questions] On Per-module process registration

[Anthony Shipman]

On Thu, 11 Feb 2010 12:29:43 pm Richard O'Keefe wrote:

> The problem it was intended to solve was the problem of code
> written according to the examples in Erlang books where a module
> controls one process and registers a name for it so that the
> module can communicate with that process, but far from any
> desire for other processes or modules to find it, the possibillity
> of other processes or modules sending messages to that process
> creates a vulnerability.

I find that these sorts of processes are in the minority, at least in the 
systems I work on.

>
> > 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.
>
> Why can't the master keep a dictionary of slaves, keyed by whatever
> it wants, as part of its state?  Since the master has to be informed
> of the slaves' deaths anyway, it can update the dictionary at the
> same time, no?

That's what I have done so far. But it creates problems. The OTP system is 
strongly biased towards using supervisors. For example, you can't do OTP code 
updates on a process that is not reachable from the OTP supervisor. It's a 
lot of code to implement for what should be a common design pattern.

>
> The question is what merit you see in unrelated
> processes being able to easily do
>
> 	exit(whereis('<scope>/<slave_id>'), kill).
>
> That's what my EEP is about.

It's probably not a good idea most of the time. But on the other hand if I 
wanted to test crash recovery or be able to kill something that's gone into 
an infinite loop it might be useful. 

The interior of an Erlang system is assumed to be a fairly benign trustworthy 
environment. If I can replace the code of a module at run-time then that's a 
bigger security risk than sending stray messages or killing processes. I'm 
not convinced that it what it addresses is a big enough problem.

>
> One might as well go all the way and unify dynamic registries and
> supervisors completely, and call them supervisors.
>
> There is one thing that a dynamic registry could do that a
> supervisor cannot do, and that is to hold unrelated/uncontrolled
> processes.
>
> It looks to me as though writing a dynamic registry module should
> not be incredibly difficult, given a design; it's just another
> plain old Erlang module.

I have implemented my own kinds of registry. What I don't have is the ability 
to atomically spawn and register a process. Perhaps just adding the ability 
to spawn a process in a paused state and then unpause it later would solve 
that problem.

-- 
Anthony Shipman                    Mamas don't let your babies 
als@REDACTED                   grow up to be outsourced.