[erlang-questions] -pidname( <atom> ) Was: Why we need a -module() attribute?

[Richard A. O'Keefe]

On 3/03/16 11:12 am, Éric Pailleau wrote:
>
> Hi,
> Could not this be solved by spawn_priv/x functions ? I mean functions 
> that do same than spawn/x but spawned process accept only messages 
> from parent process ?
> No need to change things in process registry then.
>

If we're still talking about pidnames, then the answer is NO.
(That's not to say that some such thing could not be useful, only that it
would not solve the same problem.)

Let's suppose we have
  process P calls M:foobar() which uses a local pidname
    to communicate with *module*-private process R.
  process Q calls M:zarkov() which uses the same local
    pidname to communicate with the same process R.

This is GOOD.  We're happy with it.  We are delighted
that code inside M but executed by P sends a message
to R and that code inside M but executed by a different
process Q also sends a message to R.  Not a problem!
In both cases, the message was sent by code inside M,
which knows R's protocol.

If it's a matter of a process remembering the pid of a
child process, you'd never use the process registry for
that in the first place.  You'd use the process dictionary
of the parent process.  We don't even need a new kind of
spawn: without using subversive debugging machinery, the
only processes that can send you messages are yourself and
your parent, until one of you passes the pid on to some
other process.

Note that a process that only accepts messages from its
parent, while it *could* be useful, would not be able to
create its own child and receive replies from that.