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. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
