Hi,
On Wed, Jan 28, 2015 at 04:57:19PM +0000, Ian Jackson wrote:
> Euan Harris writes ("Re: Cancelling asynchronous operations in libxl"):
> > On Tue, Jan 20, 2015 at 04:38:24PM +0000, Ian Jackson wrote:
> > > * Is an API along these lines going to meet your needs ?
> >
> > The API you propose for libxl_ao_cancel, as described in the comment in
> > libxl.h, looks reasonable to us. The comment for ERROR_NOTIMPLEMENTED
> > is a bit confusing: under what circumstances might a task actually be
> > cancelled although libxl_ao_cancel returned ERROR_NOTIMPLEMENTED?
>
> A single operation may go through phases during which cancellation is
> effective, and phases during which it is not very effective because it
> hasn't been properly hooked up. If libxl_ao_cancel is called during
> the latter, it will return ERROR_NOTIMPLEMENTED but the operation will
> still be marked as wanting-cancellation, so if it enters a phase where
> cancellation is effective, it will stop at that point.
>
> To put it another way, what libxl_ao_cancel does is:
> - find the ao in question, hopefully
> - make a note in the ao that it ought to be cancelled
> - look for something internal that has registered a
> cancellation hook
> - if such a hook was found, call it and return success;
> otherwise return ERROR_NOTIMPLEMENTED.
>
> So ERROR_NOTIMPLEMENTED is more of a hint.
>
> If you prefer, it would be possible to make libxl_ao_cancel _not_ make
> a note that the operation ought to be cancelled, in the case where
> it's returning ERROR_NOTIMPLEMENTED. Then the libxl_ao_cancel would
> be guaranteed to have no effect.
>
> But, if we do that, it won't be possible to mark a
> currently-running-and-not-promptly-cancellable but
> maybe-shortly-actually-cancellable operation as to be cancelled.
>
> Perhaps if this is confusing the better answer is simply to return a
> different error code instead of ERROR_NOTIMPLEMENTED,
> ERROR_CANCELLATION_DIFFICULT
We've discussed the semantics of cancellation a bit more off-list and
have come to two conclusions:
1. The behaviour of the current libxl_ao_cancel() proposal is more akin
to 'abort' than 'cancel'. This is because the proposed
implementation can't guarantee the state of the domain after
cancellation - it might be fine, it might be dead, or it might
be in some unanticipated limbo state, depending on just when the
cancellation call took effect.
We should rename the proposed libxl_ao_cancel() to libxl_ao_abort().
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.
2. We should remove the ERROR_NOTIMPLEMENTED error code. It does
not add much value, because cancellation is implemented in terms
of underlying primitive operations, rather than API operations.
Any async API operation may be cancellable in principle, and whether
this error code is returned depends on exactly what primitive
operation happens to be in progress when libxl_ao_cancel/_abort() is
called. Furthermore, even if the call to libxl_ao_cancel/_abort()
returns NOTIMPLEMENTED, the operation may be cancelled anyway when
it starts a cancellable primitive operation.
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.
Thanks,
Euan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
