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

[Anthony Liguori <aliguori@us.ibm.com>]

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.

Regards,

Anthony Liguori