From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Campbell <ian.campbell@citrix.com>
Subject: Re: Cancelling asynchronous operations in libxl
Date: Thu, 25 Jun 2015 11:40:54 +0100
Message-ID: <1435228854.32500.31.camel@citrix.com>
References: <0D156F8A-5D32-4559-8AD0-5E6AE3E21745@citrix.com>
	<21694.33920.188447.567330@mariner.uk.xensource.com>
	<20150128161342.GA32398@citrix.com>
	<21705.5359.937509.399671@mariner.uk.xensource.com>
	<20150624153327.GA3258@citrix.com>
	<21898.53141.267053.716749@mariner.uk.xensource.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Return-path: <xen-devel-bounces@lists.xen.org>
In-Reply-To: <21898.53141.267053.716749@mariner.uk.xensource.com>
List-Unsubscribe: <http://lists.xen.org/cgi-bin/mailman/options/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=unsubscribe>
List-Post: <mailto:xen-devel@lists.xen.org>
List-Help: <mailto:xen-devel-request@lists.xen.org?subject=help>
List-Subscribe: <http://lists.xen.org/cgi-bin/mailman/listinfo/xen-devel>,
	<mailto:xen-devel-request@lists.xen.org?subject=subscribe>
Sender: xen-devel-bounces@lists.xen.org
Errors-To: xen-devel-bounces@lists.xen.org
To: Ian Jackson <Ian.Jackson@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>, Dave Scott <Dave.Scott@citrix.com>, Stefano Stabellini <stefano.stabellini@eu.citrix.com>, Euan Harris <euan.harris@citrix.com>, Xen-devel <xen-devel@lists.xen.org>
List-Id: xen-devel@lists.xenproject.org

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.