On Fri, Jul 15, 2011 at 09:09:52 -0600, Eric Blake wrote:
> On 07/15/2011 08:41 AM, Jiri Denemark wrote:
> > When an asynchronous job is running while another API that is
> > incompatible with that job is called, we now try to wait until the job
> > finishes and either run the API or fail with timeout. I guess nicer
> > solution is to just fail such API immediately and let the application
> > retry once the asynchronous job ends.
> > ---
> > src/qemu/THREADS.txt | 5 ++---
> > src/qemu/qemu_domain.c | 28 +++++++++++++++-------------
> > 2 files changed, 17 insertions(+), 16 deletions(-)
>
> If all such APIs have a flag argument, then we could make the behavior
> configurable - passing 0 blocks until possible, and passing
> VIR_DOMAIN_OPERATION_NONBLOCK as a flag returns immediately.
>
> But we probably don't have uniform flags arguments. Which APIs are
> affected?
All APIs that modify state, currently the following list (qemu driver names):
Resume
Shutdown
Reboot
SetMemoryFlags
InjectNMI
SetVcpusFlags
Suspend
Restore
ModifyDeviceFlags
SnapshotCreateActive
RevertToSnapshot
SnapshotDelete
MonitorCommand
> If we can't control things by a flag, then returning a specific failure
> seems like the best way to go (it is easier to write an app that can
> retry than it is to write an app that doesn't suffer from unintended
> blocking).
>
> So this patch seems sane to me, although I'd still like a list of all
> affected APIs before giving ack.
BTW, the patch is not complete so acking or not would only affect the idea.
Jirka
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list