[erlang-questions] Miller's oversight

[Mark S. Miller]

ok wrote:
> 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."
> [...]
> 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
> message.


I agree. At 
<http://www.erlang.org/pipermail/erlang-questions/2006-June/020845.html> I wrote:

> On practicality, perhaps I am underestimating how lightweight Erlang processes
> are. If they are lightweight enough, then this approach would work. To whit:
> 
> When Erlang process X wishes to make a request and receive a response from
> process Y, X would make a new use-once process X2 which knows X's pid. X would
> then include X2's pid in the message to Y. When Y responds to X2, X2 would
> then wrap Y's response with a tag and send this response to X.
> 
> Either these tags can themselves be unforgeable, or X's clients would also
> need to go through a tagging intermediate process so that a client couldn't
> send a message that X would mistake for Y's tagged response. I think it works
> for X2 to tag the message with X2's (presumed unforgeable) pid, since anyone
> who has that pid can respond on behalf of Y anyway.
> 
> With enough care, X could reuse X2 for successive requests to Y. But if X
> wants to make requests of Z, it would need a separate X3 for that purpose.
> Otherwise, it enables Y to issues Z's response, and vice versa.
> 
> The above scheme would meet the hard requirements. But how practical would it be?


That's the good news. The bad news is that Erlang processIds are forgeable, 
making the above technique irrelevant. See 
<http://erlang.org/ml-archive/erlang-questions/200606/msg00206.html>.

-- 
Text by me above is hereby placed in the public domain

     Cheers,
     --MarkM