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: Sun, 25 Sep 2005 12:09:15 +0100
Cc: Andrew Warfield <andrew.warfield@xxxxxxxxxxxx>, xen-devel List <xen-devel@xxxxxxxxxxxxxxxxxxx>, Steven Hand <steven.hand@xxxxxxxxxxxx>, Christian Limpach <Christian.Limpach@xxxxxxxxxxxx>
Delivery-date: Sun, 25 Sep 2005 11:02:03 +0000
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <1127609824.796.28.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> <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> <4f7ac507bdbff3eafe3d0aaba1446e41@xxxxxxxxxxxx> <1127433079.2722.24.camel@xxxxxxxxxxxxxxxxxxxxx> <eacc82a405092218014268eae0@xxxxxxxxxxxxxx> <1127609824.796.28.camel@xxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx

On 25 Sep 2005, at 01:57, Rusty Russell wrote:

Now, we already have this "domain won't save until transactions are
done" simply because we use a single big lock, but this discussion
started because we want to get rid of that lock for /proc/xen/xenbus
(it's fine for drivers).  I think we should do so, but keep this
wont-save-during-transactions semantic; it means a waitqueue etc, but I
don't think it's too bad.  As you say, our transactions are pretty
small.

Do people like this more?

Blocking system progress on arbitrary user apps doesn't sound particularly attractive to me, but I guess it is at least simple. I'm more inclined to EAGAIN on read/write, maybe sugared by exceptions in languages that support them, or setjmp/longjmp to get you back to the outermost scope of the transaction. I agree that's not pretty either, though.

How will you handle 'xenstored restart'? You can't really guarantee that to always happen at opportune moments with no transactions in flight.

 -- Keir


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