[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 00/22] QAPI Round 1

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 00/22] QAPI Round 1
Date: Tue, 08 Mar 2011 07:35:54 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8

On 03/08/2011 05:12 AM, Avi Kivity wrote:
On 03/07/2011 05:59 PM, Anthony Liguori wrote:

How do async commands work?  You mentioned them when talking about
QAPI but it's not obvious to me that there is any "native" support for
async commands?

Async commands are interesting..

Would there be anything in them other than starting each command in its own thread? If it then drops the right locks it can execute in parallel with other commands, if it doesn't, then it's synchronous (and presumably doesn't depend on external or guest events).

I've implemented them (for virt-agent) and I'll have it in v2 of round 1.

I use callbacks. If a function is marked to be async, it generates a signature like:

typedef void (GuestViewFileCompletionFunc)(void *qmp__opaque, const char * qmp__retval, Error *qmp__err); void qmp_guest_view_file(const char * filename, Error **err, GuestViewFileCompletionFunc *qmp__cc, void *qmp__opaque);

The handler just needs to squirrel away qmp__cc and qmp__opaque and call it whenever the command completes.

OTOH, there are users that will be purely event driven that will treat every RPC asynchronously. In both cases, it's more or less all-or-nothing. Having some commands delay for really long periods of time means that you either force users to treat some commands specially, or you force all users into an event driven model.

And of course, if you have async commands, you need to cancel commands, and then the context is within a single QMP session which means that you need to figure out what to do if you drop the session while an async command is executing. For instance, if a management tool executes the migrate command, and it's implemented as an async command, if the management tool loses it's connection, should migration be automatically cancelled?

Sounds reasonable.  The rules could be:
- a command (all commands are async) takes a ref on the monitor context
- if the session is dropped, call the current command's cancel callback

as a result, a dropped session causes the command to either cancel or complete.

Yup, this is pretty much what I'm now doing.

I'm really on the fence about async commands. At the moment, I'm leaning towards just not every implementing them.

Do we have a list of candidates for async commands?

Yeah, all of the guest commands need to be asynchronous so we definitely need to support it.


Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]