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