Re: [Xen-devel] [PATCH 6/9] libxl: Asynchronous/long-running operation infrastructure

[Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>]

Ian Campbell writes ("Re: [Xen-devel] [PATCH 6/9] libxl: 
Asynchronous/long-running operation infrastructure"):
> On Tue, 2012-01-24 at 17:27 +0000, Ian Jackson wrote:
> > If ao_how is non-NULL then these functions cannot return 0.
> > If it is NULL they cannot return ASYNC_INPROGRESS.
> > 
> > I chose to use a new exit status because it seemed safer but that's a
> > matter of taste and if you prefer I could return 0 for that case.
> 
> I'm undecided (plus it seems a bit like bikeshedding). I certainly
> prefer either 0 or {LIBXL_}ASYNC_IN_PROGRESS to ERROR_ASYNC_IN_PROGRESS
> though.

OK, I'll rename it.

> > I guess we could but isn't this going to become a proper IDL enum at
> > some point ?
> 
> At which point it would become LIBXL_ERROR_{FOOS} and
> LIBXL_ASYNC_IN_PROGRESS?

I guess so.  Or we could rename it LIBXL_RC_...

> + *   * initiator calls ao_complete:               |
> + *     - observes event not net done,             |
> 
> You want s/net/yet/.

Yes.

> > > Can we arrange for AO_INPROGRESS and AO_ABORT to return the rc? So it
> > > would become
> > >         return AO_INPROGRESS;
> > 
> > That would be possible.  I wasn't sure whether to do it like that.
> > Note that AO_CREATE already might return; doing it the way I have it
> > now seems more symmetrical.
> > 
> > But perhaps it would make things clearer to have the return outside
> > the macro.
> 
> I thought there was a general preference for that sort of thing, but I
> suppose it depends on the required macro contortions to make it happen.

I think this should be easily doable.  I'll sort it out.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel