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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2013-10-28 at 15:52 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] FW: Cancelling asynchronous operations 
> in libxl"):
> > On Wed, 2013-10-23 at 13:23 -0400, Konrad Rzeszutek Wilk wrote:
> > > Are there specific operations that you are focusing on to cancel?
> > 
> > Yes, this would be good to know. Ian J would know better than I but AIUI
> > there is currently no generic support for cancelling an asynchronous op
> > in libxl. I'm sure we could find a way to add this, for example as an
> > abort after the current "step" succeeds/times out/fails.
> 
> That's right.
> 
> I think the right approach would be to provide a new kind of ao_how
> value which returns a reference to the caller which can be used for
> cancellation.
> 
> Cancellation would itself be asynchronous, in the sense that you sould
> request cancellation but then still have to wait for the operation to
> end.
> 
> So initially you could implement cancellation for only a subset of
> operations and have the infrastructure disregard cancellation requests
> for operations which don't support it.  I think the most obvious
> operation that should be cancellable is domain migration.
> 
> Ideally there would be some kind of automatic plumbing which would
> arrange (for example) that callers to the libxl xs watch functions, or
> timeout functions, would get a "cancellation" notice instead.

The way in which sequential async subops are currently handled (by
chaining callbacks) is a bit ugly -- it leads to weird error messages
like "libxl__vtpm_foo: Failed" which actually means "couldn't add a
NIC" (because that was the previous step, and libxl__vtpm_foo is what
picks up the result). Do you think it would be feasible to recast those
as sequences of function pointers in an array with a central (common)
dispatcher which steps through, handling and reporting errors?

If things could be restructured along those lines then adding
cancellation support to the dispatcher might get us reasonably good API
coverage pretty easily

Ian.


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel