Re: Persistence (was: Future Direction of GNU Hurd?)

--000000000000795c3305be3a572b
Content-Type: text/plain; charset="UTF-8"

On Sat, Mar 20, 2021 at 11:08 AM Olaf Buddenhagen <[email protected]>
wrote:


> > If I remember correctly (hey, it's only been 38 years), Mach is even
> > weirder, because a reply port is part of the *process* state rather
> > than the *thread* state. A message received by one thread can be
> > replied by a different thread in the same process, but cannot be
> > replied by a different process. This creates a strange asymmetry.
>
> Not sure what you mean? In the Mach variants I'm familiar with, the only
> special thing about reply capabilities is that they are *typcially*
> implemented using send-once rights: which can only be moved, not copied.
>

Ah. Yes. I was thinking about send-once capabilities. The move semantics on
those is damned weird, and it creates some interesting design puzzles in
certain cases.

> The other problem is that you sometimes *need* to violate
> > orthogonality. For example, you don't want to lose a committed banking
> > transaction if the system has to restart before the next checkpoint.
> > KeyKOS, EROS, and Coyotos *all* have ways to bypass the checkpoint
> > rules for this kind of situation.
> Is it possible to briefly explain how this bypassing works?


Yes.

Oh. You want me to *actually* explain it?

In brief: the database holds a specialized capability that allows it to
flush a page (or pages) to disk and add the new content of the page to the
previous checkpoint. This can only be done for data pages, and in 50 years
we've never found a credible use case for it other than database
transaction commits.

> So far as I know, Coyotos did not borrow from Viengoos.
> I didn't think it did :-) In my undestanding however, you did make some
> changes to the IPC mechanism in Coyotos, after Neal and Marcus discussed
> async requirements with you?


I had felt for a long time that the restriction to synchronous IPC was not
a good thing, but I had struggled to come up with a safe and performant
design for it. My intuition was that scheduler activations were the right
way to go at it, but there are architectures (notably ARM) where it's very
hard to do those correctly. Rich Grisenthwaite (the principal ARM
architect) was very mildly embarrassed about that.

Anyway, I think all of us were circling around the issue and prodding it to
see if there was a path out. The L4 community was also doing so at that
time. I think it's very hard to say, now, who contributed what to whom.


Jonathan

--000000000000795c3305be3a572b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Sat, Mar 20, 2021 at 11:08 AM Olaf Bud=
denhagen &lt;<a href=3D"mailto:[email protected]">olafbuddenhagen@gmx=
.net</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex">
&gt; If I remember correctly (hey, it&#39;s only been 38 years), Mach is ev=
en<br>
&gt; weirder, because a reply port is part of the *process* state rather<br=
>
&gt; than the *thread* state. A message received by one thread can be<br>
&gt; replied by a different thread in the same process, but cannot be<br>
&gt; replied by a different process. This creates a strange asymmetry.<br>
<br>
Not sure what you mean? In the Mach variants I&#39;m familiar with, the onl=
y<br>
special thing about reply capabilities is that they are *typcially*<br>
implemented using send-once rights: which can only be moved, not copied.<br=
></blockquote><div><br></div><div>Ah. Yes. I was thinking about send-once c=
apabilities. The move semantics on those is damned weird, and it creates so=
me interesting design puzzles in certain cases.</div><div><br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex">&gt; The other problem is that y=
ou sometimes *need* to violate<br>
&gt; orthogonality. For example, you don&#39;t want to lose a committed ban=
king<br>
&gt; transaction if the system has to restart before the next checkpoint.<b=
r>
&gt; KeyKOS, EROS, and Coyotos *all* have ways to bypass the checkpoint<br>
&gt; rules for this kind of situation.<br>
Is it possible to briefly explain how this bypassing works?</blockquote><di=
v><br></div><div>Yes.</div><div><br></div><div>Oh. You want me to <i>actual=
ly</i>=C2=A0explain it?</div><div><br></div><div>In brief: the database hol=
ds a specialized capability that allows it to flush a page (or pages) to di=
sk and add the new content of the page to the previous checkpoint. This can=
 only be done for data pages, and in 50 years we&#39;ve never found a credi=
ble use case for it other than database transaction commits.<br>
<br><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex">
&gt; So far as I know, Coyotos did not borrow from Viengoos.<br>
I didn&#39;t think it did :-) In my undestanding however, you did make some=
<br>
changes to the IPC mechanism in Coyotos, after Neal and Marcus discussed<br=
>
async requirements with you?</blockquote>
</div><div><br></div><div>I had felt for a long time that the restriction t=
o synchronous IPC was not a good thing, but I had struggled to come up with=
 a safe and performant design for it. My intuition was that scheduler activ=
ations were the right way to go at it, but there are architectures (notably=
 ARM) where it&#39;s very hard to do those correctly. Rich Grisenthwaite (t=
he principal ARM architect) was very mildly=C2=A0embarrassed about that.</d=
iv><div><br></div><div>Anyway, I think all of us were circling around the i=
ssue and prodding it to see if there was a path out. The L4 community was a=
lso doing so at that time. I think it&#39;s very hard to say, now, who cont=
ributed what to whom.</div><div><br></div><div><br></div><div>Jonathan=C2=
=A0</div></div></div>

--000000000000795c3305be3a572b--