[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 
> 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)

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.