[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Jonathan S. Shapiro
Subject: Re: Persistence (was: Future Direction of GNU Hurd?)
Date: Tue, 23 Mar 2021 13:50:57 -0700

On Sat, Mar 20, 2021 at 11:08 AM Olaf Buddenhagen <olafbuddenhagen@gmx.net> 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?


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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]