|
[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 |