Re: Newbie questions about persistence

On Tue, 2009-09-01 at 16:08 +0100, Thomas Leonard wrote:
> On Fri, 2009-08-28 at 19:15 -0400, Kevin Reid wrote:
> > On Aug 28, 2009, at 10:27, Thomas Leonard wrote:

[ snip persistence of facets, broken promises, files, cycles ]

> > > Persistence of identity
> [...]
> > > Therefore, most objects should use __optSealedDispatch to seal the
> > > result. There don't seem to be many examples of this (e.g. FileGetter
> > > uses "obj instanceof File" instead). I'm having trouble seeing how to
> > > use this. Should I add a new loader/uncaller?
> > 
> > No, you should use the vat-wide persistence sealer, whose unsealer is  
> > closely held by the vat persistence system, in your  
> > __optSealedDispatch. If you seal your portrayal (what you would return  
> > from __optUncall) then you will get the behavior you want without any  
> > global definitions.
> > 
> > Unfortunately, IIRC, the persistence sealer is also closely held, but  
> > there is no good reason for this. (MarkM, could you confirm this?)

OK, I modified ScopeSetup to put a "persistence" object in safeScope (I
couldn't see a way to do this from E). The main program binds this to an
object with the brand and sealer, using a resolver in privScope. Is this
sensible (at least as a work-around)?

There are 48 separate objects in my program that need it, so I'm
reluctant to start passing it around everywhere. I want to make it as
easy as possible to serialise objects in a safe way; otherwise people
will be tempted to __optUncall instead, I think.

> > > How is identity handled?
> > > e.g if I have a one-shot object, how can I ensure that an object
> > > holding it will revive with only one copy of the one-shot object?
> > > Similarly for a caretaker.
> > 
> > If your object uncalls only by request of the vat persistence sealer,  
> > then you're guaranteed that its reincarnations will only be along with  
> > the rest of the vat state. So your one-shot might be rolled back to  
> > the not-yet-fired state, but everything else will be rolled back too  
> > and in sync.
> 
> I think I still need more help here. A naive attempt would be:
[...]
> My attacker gets persisted with a single oneShot, but revives with two
> (and can therefore print "Invoking!" twice).
> 
> I suppose I could create a simple proxy to the oneShot and give that to
> the attacker. The attacker could make copies of the proxy, but they'd
> still all forward to a single oneShot.

Can someone confirm whether this is the correct approach?

Thanks!


-- 
Dr Thomas Leonard
IT Innovation Centre
2 Venture Road
Southampton
Hampshire SO16 7NP

Tel: +44 0 23 8076 0834
Fax: +44 0 23 8076 0833
mailto:tal-v5nx5w6akNyLE8xUarVfuPLx9OUvmyODWmv/[email protected]
http://www.it-innovation.soton.ac.uk