[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] Cancelling asynchronous operations in libxl



On Wed, 2015-06-24 at 16:41 +0100, Ian Jackson wrote:
> 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.)

FWIW it seems fine to me...

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.