Re: [Xen-devel] /proc/xen/xenbus supports watch?

[Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>]

On 22 Sep 2005, at 03:22, Rusty Russell wrote:

> It's not the *commit* that fails with EAGAIN, but *any operation*
> (read/write/dir, etc), in this scenario.
Well, that is more of a pain. Probably okay for Python as an exception 
gets raised and you automatically unwind the stack to the full scope of 
the transaction. More of a pain for C code. But still, it also has the 
advantage that you can fail a doomed transaction earlier -- for 
example, you can ensure that client code doesn't execute based on 
inconsistent sets of read values (i.e., read a value A before a remote 
transaction commits; read a value B after a remote transaction commits; 
where that remote transaction updates both A and B).
Either we believe some clients are fragile to reading bad/inconsistent 
data, in which case I think EAGAIN on any read/write is a good idea 
(better than massively complicating xenstored). If we believe clients 
should be robust to reading crap from the store (and many ought to be, 
because backends can't trust values written by frontends, for example) 
then we can handle doomed transactions without early report of EAGAIN 
as follows:
 * discard writes
 * return empty strings for reads (or ENOENT, so something like that).

Whatever, the client probably needs the code to realise that a bad 
thing has happened and to take appropriate action whichever strategy we 
go for. I suspect they are equivalent complexity for clients.
 -- Keir


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