[coyotos-dev] Explicit Persistence Considered Harmful
Charles Landau
clandau at macslab.com
Tue Aug 19 10:44:17 CDT 2008
If I understand your reasoning:
1. If persistence is not "all at once", then there is the potential for
server-implemented objects and the capabilities to them, held by
clients, to get out of sync, because the server and the client may be
saved at different times.
2. Because such inconsistency is a Bad Thing, the system must ensure
that such capabilities are not persistent across restart, and the client
and server must go through a reconnection protocol to reestablish
consistency.
Jonathan S. Shapiro wrote:
> On Mon, 2008-08-18 at 20:06 -0700, Charles Landau wrote:
>>> 2. Capability safety requires that one maintain a type partition between
>>> data and capabilities. If persistence is not implicit, then capabilities
>>> that reference server-implemented objects
>>> are effectively severed by restart.
>> Perhaps you mean, the capabilities must be severed to avoid an
>> inconsistent state. This is the implication of concept (a).
>
> Not so. I mean: are necessarily severed. In non-implicit persistence,
> names of objects are not durable across restart except by invocation of
> some sort of reconnection protocol.
I don't think you've shown why this is the case. I don't know why there
couldn't be a system in which a capability to a server-implemented
object, and the server itself, were both preserved across restart. Of
course they could be inconsistent, which is a Bad Thing, but you said
that wasn't the reason for severing the capability.
>>> 1. It is exceptionally hard to implement "notify on last close"
>>> semantics.
>> Possibly, but I'm not convinced this is a consequence of implicit
>> persistence.
>
> I believe that it is. The problem is that it is very difficult to know
> when the last on-disk capability to an object disappears without disk
> GC. The problem arises primarily because the object graph in all KeyKOS
> derivatives may contain cycles.
Capabilities don't disappear while on disk, so I don't see what the
problem is. You may have to bring objects into memory to trace cycles,
but the system caches objects all the time.
It seems to me that the difficulty is due to the richer semantics that
allows cycles, not the persistence.
The Dennis and Van Horn PDP-1 did not have a space bank. It deleted
objects when the last reference went away, and it had a GC that detected
cycles. It didn't have implicit persistence.
More information about the coyotos-dev
mailing list