[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



2012/2/15 Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>:
> Roger Pau Monnà writes ("Re: [Xen-devel] [PATCH 08/11] libxl: 
> Asynchronous/long-running operation infrastructure"):
>> 2012/1/26 Ian Jackson <ian.jackson@xxxxxxxxxxxxx>:
>> > +int libxl__ao_inprogress(libxl__ao *ao)
>> > +{
>> > + Â ÂAO_GC;
>> > + Â Âint rc;
>>
>> I've just started playing with this, but I've found that if you call
>> AO_INPROGRESS without adding any event it blocks forever, and I'm not
>> sure if that is a design decision or a bug. Anyway, sometimes like in
>> libxl__initiate_device_remove you might call AO_INPROGRESS without
>> adding any event, so I think it will be safe to add something like:
>
> 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.

> 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.

>> if (!CTX->watch_counter)
>> Â Â return 0;
>
> This is definitely wrong.
>
> Ian.

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.