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