Re: XenStore Watch Behavior

[John McCullough <jmccullo@cs.ucsd.edu>]

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@cs.ucsd.edu> 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