[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] XenStore Watch Behavior
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:
signature.asc _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |