On Tue, Mar 13, 2018 at 18:20:51 +0000, Daniel P. Berrangé wrote:
> On Tue, Mar 13, 2018 at 06:13:46PM +0000, Jonathan Davies wrote:
> > Thanks all the helpful replies.
> > 
> > Just to check I've understood: The design is that the call is synchronous
> > but may become asynchronous if it times out. The purpose of the timeout is
> > just to limit the window in which it might be synchronous.
> I'd say the opposite - the API is designed to be asynchronous, but you
> might get lucky and have it complete before it returns.

It's both actually :-) The API was originally designed as synchronous,
although it was implemented asynchronously for most cases. Mainly
because the action requires a guest OS to cooperate and it may not even
allow or support detaching some devices at all and the request will be
completely ignored. On the other hand, detaching USB devices in QEMU is
a rare example of implementation which is always synchronous. And if a
guest OS cooperates, the process may be very fast so in reality users
were seeing this API as synchronous because in "normal" cases the
devices were already removed at the time the API returned success (or
when they immediately checked the device after the API finished).

When we fixed the API documentation to be explicit about the
asynchronous behavior, we wanted to make sure existing users still see
it as synchronous in normal cases and the short timeout was introduced.

At the same time we could not change the return value to distinguish
between finished and requested detach.

This is quite a mess, but it was still considered better than
introducing a new detach API which could have better semantics, but all
apps using libvirt would need to adapt and possibly be able to work with
both versions anyway.


libvir-list mailing list

Reply via email to