On Thu, 2005-08-25 at 11:09 +0100, Christian Limpach wrote:
> On Thu, Aug 25, 2005 at 01:06:26PM +1000, Rusty Russell wrote:
> > Yes, it's not possible at the moment, but it must be. I'm also thinking
> > hard about catastrophic failure modes: there are always "too hard" cases
> > but I'd like to be able to SIGKILL the store and (usually) have no
> > problems.
>
> Maybe it's preferable to make the store users deal with most of this after
> all. We already know how to re-install watches, so triggering that code
> path when the store starts up again would take care of the watches.
Yes, moving watch reinitialization into the library and allowing for
spurious watch events (which IMHO clients should handle anyway) solves
the watch problem quite nicely. And it's almost free (a little more
state in the library, but that's OK).
> We will have to deal with transactions failing anyway, so if the store
> restarts in the middle of a transaction, we just return a non-fatal
> failure code and have the user deal with that.
Well, we currently don't spuriously fail transactions, because we use
locking to prevent overlapping transactions. As I've argued repeatedly,
this makes for a nicer programming model.
Having *every* operation able to return soft failure would be
particularly ugly. However, saving transactions across restarts is
actually quite trivial, so I don't think we need to go here
(transactions exist on disk already).
> Finally, I think we
> should have watches fire when they get first installed (and re-installed),
> if the node exists.
In general, we have to fire whether it exists or no: it might have been
deleted.
> The current model where we install a watch and then
> run the watch code manually doesn't work too well because the context
> we're in is most likely not the same context we would be in when the
> watch fires regularly.
Agreed; changing registration to explicitly fire the watch would
simplify things.
> Anything else?
Domain introductions are the other persistence issue, but they are also
fairly simple. Indeed, they should be placed in the store...
Thanks!
Rusty.
--
A bad analogy is like a leaky screwdriver -- Richard Braakman
_______________________________________________
Xen-tools mailing list
Xen-tools@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-tools
|
Home