[cap-talk] Styles of persistence

[Jed Donnelley]

At 12:04 AM 3/16/2008, Bill Frantz wrote:
>shap at eros-os.com (Jonathan S. Shapiro) on Saturday, March 15, 2008 wrote:
>
> >On Sat, 2008-03-15 at 16:40 -0700, Bill Frantz wrote:
> >> shap at eros-os.com (Jonathan S. Shapiro) on Saturday, March 15, 2008 wrote:
> >>
> >> >In the terminologyof the persistence literature, the KeyKos 
> style is considered orthogonal
> >> >persistence. The capture of stack is not pertinent to whether 
> the persistence is considered
> >> >orthogonal.
> >>
> >> There may be a significant difference in the ease of object upgrade
> >> between systems that save the stack as part of the persistent state
> >> and systems that don't.
> >
> >I agree. But the upgrade issue has no bearing on the 'orthogonal
> >persistence' label.
>
>My conclusion, "Therefore two different names for the two types may
>be needed." was omitted. I don't really care what these two
>slightly different persistence systems are called, so please
>suggest different names for them.


I'm afraid I don't understand the distinction you are referring to.
Can you explain what you mean by the saving of the "stack" as part
of the state in the above?  Are you referring to "processes"/active
objects that are persistent and saving a stack or stacks internal
to such active entities?

> >But your argument presumes that upgrade should be out of band. This
> >isn't an obvious conclusion.
>
>I assume in-band means you call the object and ask it to install an
>upgrade to itself. That technique has the unfortunate effect of
>requiring preplanning on the part of the programmer, adding to my
>contention that these systems offer a choice between easy
>persistence and easy upgrade.
>
>Given that this dichotomy is real, when programming for KeyKOS
>style persistence systems, the programmer must pay the same kind of
>attention to upgrade as a Unix programmer pays to persistence.

I'm really lost in the above.  Can you explain the sort of
persistence that you suggest Unix programmers must pay attention
to and what you mean by "upgrade" above?  Are you saying that
when a system with persistent processes/active objects is
upgraded then it must insure that active process state
(e.g. including stack state) must be preserved between
upgrades?

If so that's certainly a stronger form of persistence than
we had in our NLTSS system.  While we did recover processes
between system restarts and across most upgrades, all our
service processes were designed to be restartable without
loss of objects and their capabilities.  We had some 'standard'
libraries (e.g. for object header caching) that made this
relatively easy, but still the assumption was that the
persistence of the objects and capabilities was the
responsibility of the service processes - even across
restarts and most certainly across upgrades (e.g. of
the service code itself).  There was often a bit of
a tricky transition when a service code was upgraded
to a new object header form (translate the old into
the new), but such was life in our world.  Such changes
didn't happen very often.

I guess in some ways the persistence of the objects
supported by our servers was similar to the persistence
of Unix objects.  Is that what you are referring to
when you refer to the "same kind of attention to upgrade
as a Unix programmer pays to persistence."?  Are you
referring to a Unix system programmer taking care to
insure that, for example, file system integrity is
preserved across system upgrades?

I'm just guessing, but are you assuming a very different
sort of persistence mechanism in the discussion above?
It sounds like you may be assuming that processes were
made persistent not only across system upgrades, but
even necessarily across upgrades of the code in the
processes?!?  If so that sounds pretty ambitious to me.
I'd be interested to hear why you felt/feel such an
ambitious form of process state persistence was/is
necessary and how you achieved it.

--Jed  http://www.webstart.com/jed-signature.html