[erlang-questions] Miller's oversight
Mon Mar 26 00:34:20 CEST 2007
I've just started reading Mark Miller's thesis, "Robust Composition:
Towards a Unified Approach
to Access Control and Concurrency Control", or "all about E". On
page 170, writing about Erlang,
Unfortunately, a process has only one processId, so the common
convention is (sic.) for
making a request and receiving a reply is for the client to include
its own processId
in the message as a reply port. This gives the provider the
authority, not only to
reply to the client, but to invoke the client. [He means that the
receiver can not only
send the expected reply message to the originator, but can send any
number of messages
of any form, at any time.] It is not clear how to repair this
convention within the
overall Erlang framework.
My immediate reaction to this was "OK, how can we fix it?" What
would it be like to introduce
a "single-use" Pid, an atomic value which wraps a Pid so that you can
send a message to it once
but afterwards it is useless?
My second reaction was "There is no problem: Miller has overlooked
the fact that the process
the receiver replies to need not be the originator."
S = self(),
spawn(fun () -> receive M -> S!M end end).
S = self(),
spawn(fun () -> receive M -> S!M after T -> failed end end).
and all is well. There's no point in putting this in a library,
because in specific cases
you want tailored versions of the reply function that only accept the
kind of response you
want to receive.
What Miller basically overlooked is just how cheap process creation
is in Erlang. As Erlang
programmers we should not make the same mistake: we often think of
processes as long-lived,
and so they may be, but we shouldn't be afraid to make processes that
live for only a single
More information about the erlang-questions