[Fwd: Re: [e-lang] Proposal: E / Erlang integration]
Mark S. Miller
Fri Jun 9 08:46:21 CEST 2006
-------- 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-
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
More information about the erlang-questions