[erlang-questions] -pidname( <atom> ) Was: Why we need a -module() attribute?
Fri Feb 26 12:52:28 CET 2016
>> Almost all process registrations should be local to the module that
>> them. I proposed
>> for declaring a module-local atomic variable to hold pids. This would
>> be both
>> safer than the global registry and more efficient. The global registry
>> remain for those things that genuinely need to be global.
> Presuming that the module name is , say, test, how is:
> -pidname( test )
> different from:
> register( ?MODULE, self() )?
First off, let me repeat that a pidname directive declares
a MODULE-LOCAL (as in COMPLETELY INACCESSIBLE FROM THE OUTSIDE)
Second, a module name names a module, a pidname atom names a
pid variable. They are not the same thing and there is no
compelling reason for them to have the same name. Indeed, a
module may declare as many pidnames as it needs; they cannot
all have the same name as the module.
Third, -pidname just *declares* a module-local variable for
holding pids, it doesn't register anything. You'd have to
do something like pidname:set(<the atom you declared>, self()).
Fourth, just in case you missed it, the whole point is that
a pidname is strictly LOCAL to its module. It cannot even be
seen from the outside. It's private. Using the registry,
every process in the whole node can not only *see* your binding,
they can *delete* it or *replace* it. With -pidname, no can do.
You're safe, and there's no risk of you accidentally clobbering
someone else's registry entry either.
> Also, how would you run multiple instances of the same module within the
> same run-time?
Why would that even come close to the shadow of the hint of a
problem? Each instance has its OWN variable. That's what
So if you have a module that hides a process, you can load a new
version and start it, and calls still executing in the old copy
will still be routed to the old process; the registry entry won't
(can't) be hijacked by the new module instance.
> Your proposal may appear to solve one problem (that is, if one chose to
> call it a problem), but appears to introduce at least one more.
It may well do so, but you have not identified any.
It's an anachronism, because nobody had ever heard of Java
when I invented -pidname, but think of
as an analogue of
private static Thread fred = null;
More information about the erlang-questions