[e-lang] Events, threads, and return
Jonathan S. Shapiro
shap at eros-os.org
Sun Nov 28 14:55:43 EST 2004
On Sun, 2004-11-28 at 14:05 -0500, Mark Miller wrote:
> >>>"Common event patterns...map cleanly...onto threads...They
> >>>need a return event on the event model." We agree that a
> >>>return is needed, and this is where the promises come in...
> > Oddly enough, it looks like Coyotos is going to abandon this. It turns
> > out that you *don't* need a return. What you need is the ability to
> > transmit a capability on which the returned message should be sent. You
> > also need a way to invalidate this efficiently.
> Do you think the technique you're using (which I'll leave it to you to
> explain) would be suitable for general use writing complex applications? Do
> you believe it should be directly supported by a general purpose programming
> language? (The possibility hadn't occurred to me before, and it's intriguing.)
Possibly, though I think it might be wise to let us find the drain in
this particular swamp before you adopt. As you read the following,
remember that I am mainly talking about the case of returning to a
continuation that is blocked waiting for a procedure-style return.
Here is what we are doing:
At the most primitive level, *any* return mechanism requires a
capability naming a communication channel on which the message is to be
sent. This capability can name a blocked receiving continuation, as the
KeyKOS/EROS resume capability does, or it can simply name a receiving
process (vat). In the latter case, the semantics of return -- that it is
the response to a closure -- must be re-established at some higher level
In the EROS/KeyKOS model, the largest remaining removable cost is the
fabrication of the resume capability. In addition to simply being
expensive to do, the resume capability needs an invalidation mechanism
(the call count) in order to ensure that it becomes efficiently
invalidated. This is all rather a mess.
Somewhere in the various L4 discussions, it was observed (I think by
Kevin Elphinstone) that in many cases it would be more appropriate to
have a session model, in which there was a long-lived reply capability
established at start of session and subsequently reused rather than
refabricated. Responsibility for invalidation in this case falls to the
That is, the normal resume pattern can be viewed as a session setup and
teardown that exists for the duration of a single call.
We are going to try to build a hybrid mechanism in Coyotos that exploits
this option. There are some issues with regularizing the IPC interface
that we need to address, but it looks fairly well doable.
Jonathan S. Shapiro <shap at eros-os.org>
More information about the e-lang