Dave Scott writes ("Cancelling asynchronous operations in libxl"):
> I’ve re-read the thread from Nov 2013: (2013!)
> http://lists.xen.org/archives/html/xen-devel/2013-11/msg01176.html
> and found it quite thought-provoking.Thanks. However, I think the message you really want is From: Ian Jackson <ian.jack...@eu.citrix.com> To: <xen-de...@lists.xensource.com> CC: Ian Campbell <ian.campb...@citrix.com> Subject: [RFC PATCH 00/14] libxl: Asynchronous event cancellation Date: Fri, 20 Dec 2013 18:45:38 +0000 and the subsequent thread, which I can't find in the lists.xenproject.org archives but I did find for example here: http://osdir.com/ml/xen-development/2013-12/msg00472.html Getting the patch series out of the archive there will be a PITA so I have pushed it to my repo on xenbits: git://xenbits.xen.org/people/iwj/xen.git base.ao-cancel.v1-2013-12..wip.ao-cancel.v1-2013-12 What I need to know, really, is: * Is an API along these lines going to meet your needs ? * Can you help me test it ? Trying to test this in xl is going to be awkward and involve a lot of extraneous and very complicated signal handling; and AFAIAA libvirt doesn't have any cancellation facility. So if your libxl callers can exercise this cancellation functionality then that would be much easier. * Any further comments (eg, re timescales etc). > From the Xapi/Xenopsd point of view, the main feature that we’d like > is to be able to ‘unstick’ the system when it appears stuck. When > the user gets bored and hits the big red “cancel” button we’d like > the particular operation/thread/call to unblock (in a timely > fashion, it’s probably ok if this takes 30s?) and for the system to > be left in some kind of manageable state. I think it’s ok for > Xapi/Xenopsd to destroy any half-built VMs via fresh libxl calls > afterwards, so libxl doesn’t need to tidy everything itself > automatically. This is roughly what the cancellation system is supposed to do. > I think cancellation could be quite hard to test. One thing we could > do is add a counter and increment it every time we pass a point > where cancellation is possible. In some libxl debug mode we could > configure it to simulate a cancellation event when the counter > reaches a specific value. A test harness could then try to walk > through all the different cancellation possibilities and check the > system is in some sensible state afterwards. I think it might be possible to add something like that to my cancellation proposal. > We were thinking about running some number of libxl-based stateless > worker processes which would also allow us to kill them with various > signals if we really needed to. I guess in the event that libxl > cancel didn’t work for whatever reason, we could fall back to this > rather cruder approach (although this should be only in extreme > circumstances). Just killing a process executing a libxl operation is likely to leave the system in an `ugly' state. libxl ought still to be able to deal with it, in principle, but I wouldn't be surprised to find bugs lurking in this kind of area. This ought to be a last resort. Thanks, Ian. _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
