[EROS-Arch] Proxy POST
Jonathan S. Shapiro
shap@eros-os.org
Fri, 21 Sep 2001 10:34:59 -0400
This is a multi-part message in MIME format.
------=_NextPart_000_021B_01C14289.107FFAA0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
A while back, I spotted a flaw in the EROS red segment implementation. =
If the keeper key held a valid start key to a non-available process, =
callers of the red segment key would be queued on the destination =
process as normal.
The flaw is that if the keeper key is changed those invocations need to =
be retried. If the change causes the gate key to point to a different =
domain, the calls need to be redirected. Thus, whenever the keeper key =
slot is changed, and the previous keeper key is a start key, all =
processes sleeping on the destination process of the previous start key =
need to be re-awakened.
The bug is simply that the original destination process could go a long =
time before awakening, and there is no reason to stall the invocations =
that can now proceed successfully by virtue of the red seg keeper having =
changed.
Combining this mechanism with POST allows one to effectively re-assemble =
an in-kernel queue of callers if one more trick is done: queued post. =
I'm not entirely sure about how to package this, but here is the idea:
Suppose that the POST invocation takes an additional argument, or that =
we introduce into the kernel a "queued invocation" mechanism similar to =
the resume key. If the additional argument is a kept red segment, the =
POST activity will be queued on the red segment as though it had invoked =
the red segment in the first place, and will be awaked and allowed to =
proceed under the same conditions as any other invocation on that red =
segment -- that is, when the keeper becomes available.
Given this mechanism, a server can now assemble a list of processes to =
be woken up in a single operation. It performs a queued post to these =
processes, causing them to queue on a common, stalled red segment. When =
it wishes these messages to be delivered, it changes the state of the =
red segment so as to wake up all sleeping activities, causing the posts =
to "fire" and be delivered.
It is inherent in the proposed mechanism that such activities may fire =
prematurely, as when the red segment node is removed from memory. This =
can be recovered by adding an additional key to the POST activity, but =
for the moment I don't think this is worth the effort.
Jonathan
------=_NextPart_000_021B_01C14289.107FFAA0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4807.2300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>A while back, I spotted a flaw in the =
EROS red=20
segment implementation. If the keeper key held a valid start key to a=20
non-available process, callers of the red segment key would be queued on =
the=20
destination process as normal.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The flaw is that if the keeper key is =
changed those=20
invocations need to be retried. If the change causes the gate key to =
point to a=20
different domain, the calls need to be redirected. Thus, whenever the =
keeper key=20
slot is changed, and the previous keeper key is a start key, all =
processes=20
sleeping on the destination process of the previous start key need to be =
re-awakened.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The bug is simply that the original =
destination=20
process could go a long time before awakening, and there is no reason to =
stall=20
the invocations that can now proceed successfully by virtue of the red =
seg=20
keeper having changed.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Combining this mechanism with POST =
allows one to=20
effectively re-assemble an in-kernel queue of callers if one more trick =
is done:=20
queued post. </FONT><FONT face=3DArial size=3D2>I'm not entirely sure =
about how to=20
package this, but here is the idea:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Suppose that the POST invocation takes =
an=20
additional argument, or that we introduce into the kernel a "queued =
invocation"=20
mechanism similar to the resume key. If the additional argument is a =
kept red=20
segment, the POST activity will be queued on the red segment as though =
it had=20
invoked the red segment in the first place, and will be awaked and =
allowed to=20
proceed under the same conditions as any other invocation on that red =
segment --=20
that is, when the keeper becomes available.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Given this mechanism, a server can now =
assemble a=20
list of processes to be woken up in a single operation. It performs a =
queued=20
post to these processes, causing them to queue on a common, stalled red =
segment.=20
When it wishes these messages to be delivered, it changes the state of =
the red=20
segment so as to wake up all sleeping activities, causing the posts to =
"fire"=20
and be delivered.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>It is inherent in the proposed =
mechanism that such=20
activities may fire prematurely, as when the red segment node is removed =
from=20
memory. This can be recovered by adding an additional key to the POST =
activity,=20
but for the moment I don't think this is worth the effort.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Jonathan</FONT></DIV></BODY></HTML>
------=_NextPart_000_021B_01C14289.107FFAA0--