Re: [PATCH 08/11] libxl: Asynchronous/long-running operation infrastructure

[Ian Jackson <Ian.Jackson@eu.citrix.com>]

Roger Pau Monné writes ("Re: [Xen-devel] [PATCH 08/11] libxl: Asynchronous/long-running operation infrastructure"):
> 2012/2/15 Ian Jackson <Ian.Jackson@eu.citrix.com>:
> > How are you expecting this ao to complete ?
> 
> I was expecting that AO_INPROGRESS returns 0 if no events have been
> added, so I don't need to know whether I have added events or not to
> call AO_INPROGRESS.

You must always call AO_INPROGRESS.  After calling AO_CREATE you must
call AO_INPROGRESS.

You must also arrange to call libxl__ao_complete at some point.  You
may only call libxl__ao_complete from an event callback.  So you had
better have set up an event ("added" an event as you put it).

Otherwise libxl__ao_complete will never be called at all, and indeed
the synchronous call will never return.

> > If you haven't asked for
> > an event callback then presumably libxl__ao_complete will never be
> > called.
> 
> I'm talking about libxl__ao_inprogress, which is called from
> AO_INPROGRESS macro. With the current code this macro might be called
> from libxl_device_disk_remove for example without adding any events,
> because libxl__initiate_device_remove can return successfully without
> adding an event, and AO_INPROGRESS is called unconditionally.

Yes, you are right, there is a bug in libxl_device_disk_remove /
libxl__initiate_device_remove.  I hadn't spotted that the "out" path
from the old device removal code was used in a success case too.

I will fix it.

Ian.