[Qemu-devel] Re: [RFC][PATCH v1 05/12] qapi: fix handling for null-return async callbacks

[Luiz Capitulino]

On Fri, 25 Mar 2011 16:22:16 -0500
Anthony Liguori <address@hidden> wrote:

> On 03/25/2011 02:47 PM, Michael Roth wrote:
> > Async commands like 'guest-ping' have NULL retvals. Handle these by
> > inserting an empty dictionary in the response's "return" field.
> >
> > Signed-off-by: Michael Roth<address@hidden>
> > ---
> >   qmp-core.c |    5 ++++-
> >   1 files changed, 4 insertions(+), 1 deletions(-)
> >
> > diff --git a/qmp-core.c b/qmp-core.c
> > index e33f7a4..9f3d182 100644
> > --- a/qmp-core.c
> > +++ b/qmp-core.c
> > @@ -922,9 +922,12 @@ void qmp_async_complete_command(QmpCommandState *cmd, 
> > QObject *retval, Error *er
> >       rsp = qdict_new();
> >       if (err) {
> >           qdict_put_obj(rsp, "error", error_get_qobject(err));
> > -    } else {
> > +    } else if (retval) {
> >           qobject_incref(retval);
> >           qdict_put_obj(rsp, "return", retval);
> > +    } else {
> > +        /* add empty "return" dict, this is the standard for NULL returns 
> > */
> > +        qdict_put_obj(rsp, "return", QOBJECT(qdict_new()));
> 
> Luiz, I know we decided to return empty dicts because it lets us extend 
> things better, but did we want to rule out the use of a 'null' return 
> value entirely?

For asynchronous commands you mean? No we didn't.

*iirc*, what happens today is that no command using this api is truly async,
for two reasons. First, changing from sync to async can break clients (that
happened to query-balloon). Second, although I can't remember the exact
details, the api that exists in the tree today is limited.

But for a new thing, like QAPI, having different semantics for async commands
seems the right thing to be done (ie. delaying the response).

> 
> For a command like this, I can't imagine ever wanting to extend the 
> return value...
> 
> Regards,
> 
> Anthony Liguori
> 
> >       }
> >       if (cmd->tag) {
> >           qdict_put_obj(rsp, "tag", cmd->tag);
>