Hi, Firstly, sorry for the extreme lateness of this reply!
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. 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. 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. 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). Anyway, sorry again for the lateness! Cheers, Dave _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel
