On Sat, 2005-08-13 at 09:36 +0100, Keir Fraser wrote:
> On 13 Aug 2005, at 05:23, Rusty Russell wrote:
>
> > (3) In future, xs transactions should probably be enhanced to have more
> > than one non-intersecting root. Transactions have an explicit root
> > argument because we can implement transactions reasonably efficiently
> > without needing EAGAIN on commit. They only have one root because that
> > was simple, but that means that the tools have to use "/domain" if they
> > want to set up front and backends simultaneously 8(
>
> What do you have against EAGAIN?
You are the second person from Cambridge to query this; strange that I
thought it obvious.
The Unix experience with EINTR has shown, dramatically and repeatedly,
that these kind of spurious failures make for unreliable systems. It's
a shockingly bad API, at best a 7 on the Hard to Misuse scale.
There are times when we must, reluctantly, admit failure and sacrifice
the beauty of others' code upon the rock of our requirements. This is
not one of those times.
> If you need to deal with transaction failure anyway (out of memory,
> xenstored restarted, etc.) what would be so bad about having
> transactions fail due to conflicts?
You fail in those cases (although xenstored restart will be handled for
you RSN) because something is badly wrong. The daemon is dead, we're
out of memory. file descriptors, whatever. You clean up, the operation
is over, the hamster is dead, time to go home.
> I think that having to specify root(s) up front at transaction start is
> quite a shame.
Actually, it's *brilliant*. The store is a hierarchy, and so it fits
well: our permissions and access models are based on that hierarchy so
you've got wider problems if you're spewing data all over the place. It
coaxes the programmer not to do open-ended transactions, but think about
when and why to do a transaction.
An API must be judged by the quality of the code on both sides of it,
and we'll see my judgement vindicated in this case, despite xend's best
efforts.
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