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] XenStore Watch Behavior

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Xen-devel] XenStore Watch Behavior
From: John McCullough <jmccullo@xxxxxxxxxxx>
Date: Mon, 28 Aug 2006 19:22:52 -0700
Delivery-date: Mon, 28 Aug 2006 19:23:39 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060829004830.GC23281@xxxxxxxxxxx>
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>
Mail-followup-to: xen-devel@xxxxxxxxxxxxxxxxxxx
References: <20060826203222.GA2835@xxxxxxxxxxx> <C1177152.1685%Keir.Fraser@xxxxxxxxxxxx> <20060829004830.GC23281@xxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Mutt/1.5.12-2006-07-14
On Mon, Aug 28, 2006 at 05:48:31PM -0700, John McCullough wrote:
> On Sun, Aug 27, 2006 at 03:57:06PM +0100, Keir Fraser wrote:
> > On 26/8/06 9:32 pm, "John McCullough" <jmccullo@xxxxxxxxxxx> wrote:
> > 
> > >     What is the intended behavior of watches on the XenStore?  Should
> > > only one watch be allowed on a given sub-hierarchy?  Should the most
> > > specific watch be triggered alone?  Should all watches be triggered?
> > 
> > I believe it's all supposed to work in a very obvious and simple way: All
> > watches registered on a prefix of the updated node's path should be fired. A
> > single transaction can fire the same watch multiple times if that watch is
> > on a common prefix of a number of nodes updated by that transaction (since
> > each firing event specifies the full path of the modified node, so events
> > can't really be merged).
> > 
> > If you observe different behaviour from this then it is most likely a bug
> > and we would love to receive patches!
> >
> 
> I am attaching a band-aid style patch for xswatch.  I haven't dug very
> far into the xenstore code yet, and I'm not sure how much time I have to
> dedicate on this quite yet.
> 
> What this patch addresses is xswatch's tendency to receive watches for
> non-xswatch created watches with those tokens.  Is the indended behavior
> of read_watch to pick up on all available watches and leave you to
> discriminate which to service based on token?
>

Recently I discovered that my watch and the xswatch were receiving
alternating watches (both in python).  Looking at xs_read_watch in 
tools/xenstore/xs.c, the mutex on the xshandle forces all xs_read_watch
calls to take turns.  Given that the python interface shares a single
xshandle, this prevents multiple watches.

Creating an entirely new xshandle for each use of read_watch works.
Moving to a model where the xsutil.xshandle() call creates a new
xshandle seems easily supportable, given that xswatch is primarily used,
and it keeps a reference to it's own handle.

Does anyone know of other xshandle() uses that warrant the current
behavior?

Regards,
John

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