From mboxrd@z Thu Jan 1 00:00:00 1970 From: John McCullough Subject: Re: XenStore Watch Behavior Date: Mon, 28 Aug 2006 19:22:52 -0700 Message-ID: <20060829022252.GG23281@cs.ucsd.edu> References: <20060826203222.GA2835@cs.ucsd.edu> <20060829004830.GC23281@cs.ucsd.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <20060829004830.GC23281@cs.ucsd.edu> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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" 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