[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-tools] Re: [PATCH 1/3] Recover transaction on restart, give transactions IDs



On Tue, Sep 27, 2005 at 02:37:10PM +1000, Rusty Russell wrote:
> > I don't agree with this approach since it relies on the fact that
> > we won't suspend/resume within a transaction.
> 
> If we suspend/resume over transactions, this mechanism will not work by
> itself, it will still work for local tools over xenstored restart.

Yes!

> But transactions are a privileged operations (either in-kernel
> or /proc/xen/xenbus), and are short, so I don't see it as being an
> issue.  If it becomes an issue, I'd much rather do transaction migration
> than present a horrible API to xenstore users for such a corner case.

No, please don't go there, transaction migration is a horrible idea!

> As predicted, the change to have xs_transaction_end return EAGAIN made
> the kernel code uglier and caused bugs (thanks Keir for the fixes so
> far).  Returning EAGAIN from arbitrary operations is going to make it
> worse.  I'm convinced we don't want to go there.

That's because you can write all this code much simpler if you
do something like:
 again:
  ...
  err = xs_xxx(yyy);
  if (XS_CHECK_ERR(err, again))
    real error path

with:
#define XS_CHECK_ERR(err, label) ({     \
        if ((err) == -EAGAIN)           \
                goto label;             \
        (err);                          \
})

That keeps all the code just as simple as it was before we had
to handle EAGAIN everywhere.

    christian


_______________________________________________
Xen-tools mailing list
Xen-tools@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-tools


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.