Backing up one more step...
Bryan Ford
baford@schirf.cs.utah.edu
Tue, 06 Dec 94 11:27:13 MST
>Consider an individual user's process in persistence district A. It
>takes a page fault, and needs to acquire a new page. Two
>possibilities devolve:
>
> a) Space Bank is within district A. No problem.
>
> b) Space Bank is in some other district B.
>
>For "Space Bank" you can substitute any object you like. The issue of
>importance is that a message crossed from one district to another.
>
>To invoke the Space Bank, the domain (or some domain acting on it's
>behalf) must send a message that passes from district A to district B.
>The instant the message crosses the boundary both districts must be
>tied so that they checkpoint together at the next checkpoint. The
>effect is that districts must be dynamically combined, which is NOT at
>all straightforward. It quickly defeats the benefits of districting.
I wasn't proposing to try to maintain consistency automatically between
different districts - just keep them completely independent. As I said
in my first posting, _all_ connections between two districts get severed if
_either_ of them dies and restarts. If they are to be reconnected, the
reconnection must be done manually - e.g. by looking up new keys in
a nameserver or filesystem or something. (This reconnection could be
made transparent to most of the code within the district by created
"boundary processes" around the perimeter of the district.) The theory
is that the system will be structured such that connections between
districts will be few and well-defined enough that the burden of
reconnection at the boundaries will be tolerable.
In general, this "boundary issue" applies to any persistent OS,
including KeyKOS. You _always_ have to draw some kind of boundary
around all the processes and data that you want to be persistent,
and any connections across the boundary between non-persistent
and persistent parts of the system (e.g. device drivers) must be
handled specially, with the knowledge that some kind of manual
reinitialization or reconnection will be required on restart.
I'm simply proposing to make those persistence boundaries more
flexible and finer-grained.
Bryan