Re: [Xen-devel] [PATCH] libxenstore: filter watch events in libxenstore when we unwatch

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Julien Grall writes ("Re: [PATCH] libxenstore: filter watch events in 
libxenstore when we unwatch"):
> On 09/21/2012 04:45 PM, Ian Jackson wrote:
> > The num_strings thing is obsolete.  There will always be two strings.
> > Also xs_count_strings walks the array.
> 
> We can't assume that XS_WATCH_EVENT will always equal to 2. So we need
> to browse until we find the right string. I use xs_count_strings because
> it allows to not take care of the length message in the loop.

You mean XS_WATCH_TOKEN.  And yes, we can assume that XS_WATCH_TOKEN
will always equal 1.  What is obsolete is the idea that it might be
anything different.

> >> +  /* Clear the pipe token if there are no more pending watches. */
> >> +  if (list_empty(&h->watch_list) && (h->watch_pipe[0] != -1)) {
> >> +          while (read(h->watch_pipe[0], &c, 1) != 1)
> >> +                  continue;
> >> +  }
> > 
> > I'm not convinced this is necessary.  Don't callers already need to
> > cope with potential spurious signallings of the watch pipe ?
> 
> I base my code on xs_read_watch. As I understand xs_read_watch, it will
> wait on a condition until the list is not empty.
> So if the list is empty and not the pipe, an event can occur and block
> the application (with xs_read_watch).

xs_read_watch can only be correctly be used if you are determined to
wait, right there, until a particular watch turns up.

If you are using xs_fileno, you must do as the comment says:
 * Callers should, after xs_fileno has become readable, repeatedly
 * call xs_check_watch until it returns NULL and sets errno to EAGAIN.
 * (If the fd became readable, xs_check_watch is allowed to make it no
 * longer show up as readable even if future calls to xs_check_watch
 * will return more watch events.)

I agree that the comments in xenstore.h about this are less than
clear.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel