[cap-talk] Styles of persistance

[Sam Mason]

On Thu, Apr 03, 2008 at 05:11:48PM -0700, Bill Frantz wrote:
> shap at eros-os.com (Jonathan S. Shapiro) on Monday, March 31, 2008 wrote:
> 
> >In most cases, the best way to upgrade an object is to serialize its
> >state, instantiate the new version, and have the new version read in the
> >old state (possibly using an intermediate, transient format converter to
> >separate out the conversion logic).
> >
> >To the extent that this is true, the only objects requiring a complex
> >upgrade protocol are objects that require on-line update.
> 
> Perhaps an interesting use case is the
> KeyKOS/EROS/CapROS/Coyotos(?) space bank. Instances of the space
> bank have life-times from minutes to the life of the system.
> Serialization is not used to move it from system to system. :-) It
> has a significant internal data structure to keep track of
> in-use/free, and the objects to be rescinded when a space bank is
> zapped. And, as allocation strategies change, it is likely to need
> to be changes.
> 
> It would be useful to get the upgrade path for the space bank right
> in the first release.

How did KeyKOS/EROS handle code upgrades/bug fixing?  With system
lifetimes of years I'd expect it would be handled and the problem was
solved somehow, but I'm not sure how.  Or do you just sidestep the
problem by making the spacebank so basic that it functions more like
mmap (or whatever malloc uses these days) in unix systems.


  Sam