Re: [Xen-devel] XenStore Watch Behavior

[Ewan Mellor <ewan@xxxxxxxxxxxxx>]

On Mon, Aug 28, 2006 at 07:22:52PM -0700, John McCullough wrote:

> 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.

I'm confused as to what you're trying to do, so perhaps you could start again
at the top.

xswatch starts a thread, and that thread handles all calls to xs.read_watch,
and dispatches appropriate callbacks when the watch fires.  I expect that you
would simply create a new instance of xswatch, and then everything else would
be handled for you.  What's giving you problems?

Ewan.

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