|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] XenStore Watch Behavior
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?
Something that has recently perplexed me, is when using the watch during
the save/restore process, my handler won't receive watches where the
value written in the store has an underscore. In the shutdown
situation, the underscore value is passed. I am at a loss to guess why
this is happening.
-John
xswatch-fix.diff
Description: Text document
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
|
|