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

[Anthony Liguori]

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