[erlang-questions] On Per-module process registration
Sat Feb 13 06:44:58 CET 2010
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
> 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
Anthony Shipman Mamas don't let your babies
grow up to be outsourced.
More information about the erlang-questions