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

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("Re: [Xen-devel] FW: Cancelling asynchronous operations in 
libxl"):
> On Fri, 2013-11-08 at 18:38 +0000, Ian Jackson wrote:
> > I've been thinking about this some more and looking at the code.
> > 
> > I have the following sketch of an approach:

I have now an RFC patch series, which I'm going to send as a reply to
this email.

> >  * Somehow the ao_how API is changed to make it possible to return the
> >    ao to the caller (in the case of an asynchronous ao).

I did this differently.

The caller is expected to provide a copy of their previous ao_how,
which hopefully is sufficiently unique (this is the responsibility of
the application).  This seems to deal satisfactorily with the lifetime
issues.

> The following 6 things are all internal to libxl, right?
> [stuff]

Yes.

> >  * The fork machinery is changed to take an ao, and register a
> >    cancellation hook.  A suitable-for-default-uses cancellation hook
> >    function is provided which sends SIGKILL to the child and makes a
> >    note that this has happened.  The child death callback provides an
> >    rc value (0 for status==0, or FAIL or CANCEL) for the convenience
> >    of the next layer up.

I have not yet done this in my RFC series.

> > A tricky question arises regarding cleanup: for example, if
> > libxl_domain_create_* were cancelled.  It would end up in
> > domcreate_complete with rc==CANCEL.
> > 
> > Should it now run the domain destruction ?  How would the caller say
> > they wanted that cancelled, if that too was taking too long ?  Perhaps
> > there should be a progress callback to say "we have finished
> > cancelling the first thing and are now cleaning up".

I decided to not do the destruction in the cancellation case.

Ian.

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