[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] Cancelling asynchronous operations in libxl
Euan Harris writes ("Re: Cancelling asynchronous operations in libxl"): > We've discussed the semantics of cancellation a bit more off-list and > have come to two conclusions: > > 1. [...] > > We should rename the proposed libxl_ao_cancel() to libxl_ao_abort(). Unless someone objects to this, I will do this in my next rebase/resend. (CCing a slightly wider set of people who may be interested in libxl API semantics.) > This function will be defined as a best-effort way to kill an > asynchronous operation, and will give no guarantees about the > state of the affected domain afterwards. We may add a true > libxl_ao_cancel() function later, with better guarantees about the > state of the domain afterwards. libxl_ao_abort(), as defined here, > covers many of our requirements in Xapi. My plan for implementing (eventually) libxl_ao_cancel is that it works my like abort, except that operations can: * block and unblock cancellation during critical sections * declare an ao "committed", causing cancellation requests to all fail * divert cancellation requests to a special handler (which could start to try to undo the operation, for example) ... > The semantics of libxl_ao_cancel/_abort() are defined as best effort, > so it suffices to have just two return codes: > > 0: The request to cancel/abort has been noted, and it may or may > not happen. To find out which, check the eventual return code > of the async operation. > > ERROR_NOTFOUND: the operation to be cancelled has already completed. ERROR_NOTFOUND might also mean that the operation has not yet started. For example, the call to libxl_domain_create_new might be on its way into libxl and be waiting for the libxl ctx lock. Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |