Re: [Xen-devel] [PATCH] fix race condition between libvirtd event handling and libxl fd deregister

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("Re: [PATCH] fix race condition between libvirtd event 
handling and libxl fd deregister"):
> Can we provide, or (more likely) require the application to provide, a
> lock (perhaps per-event or, again more likely, per-event-loop) which
> must be held while processing callbacks and also while events are being
> registered/unregistered with the application's event handling subsystem?
> With such a lock in place the application would be able to guarantee
> that having returned from the deregister hook any further events would
> be seen as spurious events by its own event processing loop.

I think this might be difficult to get right without deadlocks.

...
> Last half brained idea would be to split the deregistration into two.
> libxl calls up to the app saying "please deregister" and the app calls
> back to libxl to say "I am no longer watching for this event and
> guarantee that I won't deliver it any more". (Presumably this would be
> implemented by the application via some combination of the above). This
> could be done in a somewhat compatible way by allowing the deregister
> hook to return "PENDING".

This is in fact straightforward and is a subset of the existing API.
If we have libxl always call timeout_modify with abs={0,0}, it will
get timeout_occurred when the application's event loop has dealt with
it.  We can simply never call timeout_deregister.

I have implemented this in the 2-patch RFD series I'm about to send.
NB this series has been complied but not (as yet) executed by me...

Ian.

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