WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

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

To: Rusty Russell <rusty@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] /proc/xen/xenbus supports watch?
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Thu, 22 Sep 2005 10:35:10 +0100
Cc: xen-devel List <xen-devel@xxxxxxxxxxxxxxxxxxx>, Steven Hand <steven.hand@xxxxxxxxxxxx>, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Thu, 22 Sep 2005 09:28:00 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1127355755.7567.24.camel@xxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <5d7aca9505090801025f3d5771@xxxxxxxxxxxxxx> <3d8eece205090803381b818f18@xxxxxxxxxxxxxx> <1126226609.25110.3.camel@xxxxxxxxxxxxxxxxxxxxx> <3d8eece205091302422ac74f77@xxxxxxxxxxxxxx> <1126657264.7896.20.camel@xxxxxxxxxxxxxxxxxxxxx> <1126689530.4415.10.camel@xxxxxxxxxxxxxxxxxxxxx> <3d8eece205091405555a2871fc@xxxxxxxxxxxxxx> <1126748390.12119.33.camel@xxxxxxxxxxxxxxxxxxxxx> <aad156145bec3bd706ef69c0e96341a7@xxxxxxxxxxxx> <1126945564.29203.116.camel@xxxxxxxxxxxxxxxxxxxxx> <bf4f0a8e8b96fd1ac2701daa78ca52c6@xxxxxxxxxxxx> <1127088661.23870.47.camel@xxxxxxxxxxxxxxxxxxxxx> <d7335251fd831e43f944d94e22da3878@xxxxxxxxxxxx> <1127214064.2656.45.camel@xxxxxxxxxxxxxxxxxxxxx> <61d8a8d77f6cbe2402b6a05810bd9447@xxxxxxxxxxxx> <1127355755.7567.24.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

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