At 2:36 PM -0800 4/27/98, Jonathan S. Shapiro wrote:
>I have just gotten off of the phone with Norm. We've tentatively come
>to the conclusion that the "current checkpoint number" should be
>obtained from a kernel key.
The issue is, can you afford a system call for the data? In the KeyKOS journalizing code, the journalizer accessed that information for every journal entry. I think it could be modified to only update the information when it was about to overwrite a "current" journal entry. If it can be so modified, then the cost of the system call will be small.
>
>The change is in anticipation of someday having multiple checkpoint
>regimes in the same system. In such a design, the answer to the
>question "what is the current checkpoint?" is caller-dependent. In
>some implementations, regimes may be dynamically constructed, so it's
>not enough to have a per-regime journal page.
>
>A separate question is whether the "last checkpoint" information
>should be time of day based. First, I'm unclear on the semantics of
>this in a multi-regime design. Should this mean that ALL regimes are
>guaranteed to have passed the tick, or that MY regime is guaranteed to
>have passed the tick (I think the answer should be MY regime).
The whole issue of multiple checkpoint regime depends on what communication there is between regimes. The simple case is that there is none, and then MY regime is good enough. More complex cases come when two or more regimes are restarted from different places in their execution. It seems obvious to me that you don't want calling-a-resume key type coroutine relations to cross such regime boundaries.
Completely severing the relation and rebuilding it after a restart begins to look very much like classic distributed processing over a network. I assume that problem has been completely solved. :-)
Bill Frantz | If hate must be my prison | Periwinkle -- Consulting (408)356-8506 | lock, then love must be | 16345 Englewood Ave. frantz@netcom.com | the key. - Phil Ochs | Los Gatos, CA 95032, USA