From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ian Campbell Subject: Re: FW: Cancelling asynchronous operations in libxl Date: Thu, 31 Oct 2013 17:09:12 +0000 Message-ID: <1383239352.5436.13.camel@dagon.hellion.org.uk> References: <4B8F5D33B081C044AA43634E84ED7F9616A83D@AMSPEX01CL03.citrite.net> <20131023172329.GE28413@phenom.dumpdata.com> <1382776392.22417.179.camel@hastur.hellion.org.uk> <21102.34850.365297.10422@mariner.uk.xensource.com> <1383227549.25018.60.camel@dagon.hellion.org.uk> <21106.27135.289465.658185@mariner.uk.xensource.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <21106.27135.289465.658185@mariner.uk.xensource.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Ian Jackson Cc: Simon Beaumont , "xs-devel@lists.xenserver.org" , "xen-devel@lists.xen.org" List-Id: xen-devel@lists.xenproject.org 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.