[Xen-devel] Cancelling asynchronous operations in libxl

[Dave Scott <Dave.Scott@xxxxxxxxxx>]

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@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel