|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH 8/9] libxl: Introduce libxl__ev_devstate
Ian Campbell writes ("Re: [Xen-devel] [PATCH 8/9] libxl: Introduce
libxl__ev_devstate"):
> On Fri, 2012-01-13 at 19:25 +0000, Ian Jackson wrote:
> > Provide a new-style asynchronous facility for waiting for device
> > states on xenbus. This will replace libxl__wait_for_device_state,
> > after the callers have been updated in later patches.
>
> Is event-with-timeout likely to be a useful/common enough pattern to be
> worth baking into the infrastructure/helpers rather than implementing
> just for this one event type? (if yes then, "I will refactor for the
> second user is a valid response").
I'm not convinced. I thought of this but I think it would result in
flabby code - all the libxl__ev_register functions would gain a new
timeout parameter (and note that the timeout machinery has both
absolute and relative timeouts...)
I think when we have a second user it might be worth seeing if some
commonality could be extracted but TBH I doubt it would make the code
smaller or simpler.
> > +static void devstate_timeout(libxl__egc *egc, libxl__ev_time *ev,
> > + const struct timeval *requested_abs)
> > +{
> > + EGC_GC;
> > + libxl__ev_devstate *ds = CONTAINER_OF(ev, *ds, timeout);
> > + LIBXL__LOG(CTX, LIBXL__LOG_DEBUG, "backend %s wanted state %d "
> > + " timed out", ds->watch.path, ds->wanted);
> > + libxl__ev_devstate_cancel(gc, ds);
>
> What prevents racing here with the watch happening? Might the caller see
> two callbacks?
static inline void libxl__ev_devstate_cancel(libxl__gc *gc,
libxl__ev_devstate *ds)
{
libxl__ev_time_deregister(gc,&ds->timeout);
libxl__ev_xswatch_deregister(gc,&ds->watch);
}
So, no. When the timeout happens, the ev xswatch is deregistered and
can thereafter no longer generate callbacks. If there are any
xenstore watch events in the pipeline for deregistered ev_xswatch's,
they're discarded by watchfd_callback.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |