[Fwd: Re: [e-lang] Proposal: E / Erlang integration]

[Mark S. Miller]

-------- Original Message --------
Subject: Re: [e-lang] Proposal: E / Erlang integration
Date: Fri, 09 Jun 2006 01:23:32 -0400
From: Eric Northup <digitale -at- digitaleric.net>
Reply-To: Discussion of E and other capability languages	<e-lang -at- 
mail.eros-os.org>
To: Discussion of E and other capability languages <e-lang -at- 
mail.eros-os.org>,   erlang-questions -at- erlang.org

On Thu, 2006-06-08 at 20:34, Mark S. Miller wrote:
> > I am thinking about a setup where an "e-process" is actually composed
> > from several erlang processes: one for receiving events, one to do the
> > actual job, and maybe some more.
> 
> 
> 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?

Coyotos will be using essentially this scheme, so I sure hope it's
practical ;-).  It is not difficult for an IDL compiler to emit the
appropriate routines in C; for a more dynamic language, a
session-wrapper factory would be feasible.  Coyotos introduces a new
primitive object - the First Class Receive Buffer - whose behavior is a
hard-coded implementation of the forwarding-and-tagging process X2, and
Erlang could implement the same optimization.

So if by "practical", you mean "fast", then the design you describe
seems plausible.

-Eric