Re: FW: Cancelling asynchronous operations in libxl

[Ian Campbell <Ian.Campbell@citrix.com>]

On Thu, 2013-10-31 at 14:32 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] FW: Cancelling asynchronous operations in libxl"):
> > 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?
> 
> Hmmm.  It might be.  There's a problem in that they all tend to have
> different arguments.  And the control flow would be split into two
> places.
> 
> Maybe it would be better to improve the error reporting to not rely on
> the function name (which is TBH pretty pants anyway).

Yes. Even just adding a foo_done step would be better. e.g.:

do_nic_stuff -> nic_stuff_done (check nic errors) -> do_vtpm_stuff(vtpm
stuff)

rather than do_nic_stuff -> do_vtpm_stuf(check nic errors, vtpm stuff)
> 
> > If things could be restructured along those lines then adding
> > cancellation support to the dispatcher might get us reasonably good API
> > coverage pretty easily
> 
> Hmm.
> 
> Writing the control flow of all of these in a declarative style would
> be difficult.  There are a lot of ifs and some parallel loops, as well
> as simple sequential execution.

ifs seems like the easier case, you call the function and it returns a
code saying "done" without doing anything (if its that sort of if)
instead of "async work started" or you handle the two cases in the
function etc.

Don't the parallel loops coalesce into a single "everything done"
callback at some point? That seems to obvious place to resync with the
dispatcher.

> I think we would be in danger of writing a full-on coroutine system.
> Maybe that wouldn't be such a bad idea.

Indeed ;-)

> 
> Hmm.
> 
> Ian.