XenStore Watch Behavior

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

[-- Attachment #1.1: Type: text/plain, Size: 1574 bytes --]

Hello,
    I have noticed some issues with watches on XenStore.  Mainly that
multiple watches on the same node in a hierachy or a watch on a node and
a child of that node do not fire as one might expect.
    I have been working on hvm domain forking and I am using the
XenStore to communicate between xend and the qemu-dm.  The first issue
that I noticed was that you cannot use a single node to communicate
state.  Only one of the watches on the node would fire and no
communication could occur.
    Using two nodes for bidirectional communication worked fine in
normal operation, however, I discovered that during shutdown some other
watch existed on the domain's path in the store and it blocked the
watches on the xend side.  Initially I was using a combination of
xswatch with a Semaphore to perform blocking reads and the xswatch
function was never getting triggered.  I changed to using the interface
more directly via xs.watch and xs.read_watch.  I could block and read
data, but after my own function terminated the xswatch interface would
try to execute my token as an xswatch token.  Adding a no-op .fn and
empty .args and .kwargs to my token let this pass through.
Unfortunately in general operations before guest destruction the changes
that I wanted to be caught by xs.read_watch were being consumed by an
unrelated xs.watch.
    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?

Regards,
John McCullough

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 138 bytes --]

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