qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 00/36] post-Eric's fixes, QAPI improvements


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH 00/36] post-Eric's fixes, QAPI improvements
Date: Fri, 25 Sep 2015 18:21:38 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

address@hidden writes:

> From: Marc-André Lureau <address@hidden>
>
> Hi,
>
> I have grown a qapi branch during the past 2 months that was
> post-poned for review until the introspection and other fixes got
> merged or ready.
>
> It could be splitted roughly in 3 parts, but since they depend on each
> other, it make sense to send as one:
>  1. generate QAPI documentation from schema (1->12)
>  2. remove use generated qmp dispatch in monitor (13->20)
>  3. add some support for async commands (22->36)
>
> 1 and 2 are hopefully not controversial, however 3 was discussed
> previously in 'async commands with QMP' thread:

Parts 1 and 2 sound enticing!

> QMP was initially designed with async support, but the implementation
> was buggy, since the async context didn't hold the request 'id', and
> thus it wasn't really used, so it was removed in 65207c59d a few
> months ago.
>
> However, there a valid reasons to want better async support. Many qmp
> operations take time, and it's not a good idea to block the monitor
> during this time. Also, some operations, such as screendump with QXL,
> have to reenter the loop in order to complete. Furthermore, the
> current protocol is not purely synchronous, since the client have to
> handle unexpected in the middle replies, such as events.
>
> The current status-quo for async commands is to return immediately,
> and send loosely related events later. This is quite poor from an API
> point of view, and the events are not related to a previous command
> (they don't hold the request 'id'). They are also broadcasted, which
> may not make sense to other clients for various commands (all the dump
> & query for example) and this prevent from adding meaningful client
> 'id' field (since it may conflict with other clients 'id').
>
> I propose to re-introduce a better 'async' support, where command may
> return with the request 'id' only to the caller, when they are
> finished, and not block the monitor. This will be opt-out, so existing
> code do not have to change.  Furthermore, since reply order is not
> guaranteed, clients will have to have the new 'async' capability to
> use those async commands. This scheme is not incompatible with having
> additional commands to query the command status, or broadcast related
> events to all clients.

This needs thought, and probably some debate.

With Eric's series and yours on top I'm again thoroughly swamped.  My
current idea to avoid despair and ensure progress is to doggedly review
some patches every day, and not think about the length of the queue.

Unfortunately, that means it'll take me a while to reach part 3.



reply via email to

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