[e-lang] Newbie questions about persistence
tal at it-innovation.soton.ac.uk
Mon Sep 14 11:08:22 EDT 2009
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?
Dr Thomas Leonard
IT Innovation Centre
2 Venture Road
Hampshire SO16 7NP
Tel: +44 0 23 8076 0834
Fax: +44 0 23 8076 0833
mailto:tal at it-innovation.soton.ac.uk
More information about the e-lang