[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread
From: |
Eric Blake |
Subject: |
Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread |
Date: |
Thu, 7 Sep 2017 08:59:23 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 |
On 09/06/2017 06:31 AM, Dr. David Alan Gilbert wrote:
>> This does imply that you need a separate monitor I/O processing, from the
>> command execution thread, but I see no need for all commands to suddenly
>> become async. Just allowing interleaved replies is sufficient from the
>> POV of the protocol definition. This interleaving is easy to handle from
>> the client POV - just requires a unique 'serial' in the request by the
>> client, that is copied into the reply by QEMU.
>
> OK, so for that we can just take Marc-André's syntax and call it 'id':
> https://lists.gnu.org/archive/html/qemu-devel/2017-01/msg03634.html
>
> then it's upto the caller to ensure those id's are unique.
We ALREADY support 'id', and it is already up to the caller to ensure
those id's are unique, even without Marc-André's additions.
>
> I do worry about two things:
> a) With this the caller doesn't really know which commands could be
> in parallel - for example if we've got a recovery command that's
> executed by this non-locking thread that's OK, we expect that
> to be doable in parallel. If in the future though we do
> what you initially suggested and have a bunch of commands get
> routed to the migration thread (say) then those would suddenly
> operate in parallel with other commands that we're previously
> synchronous.
Presumably, all existing commands are NOT async, and introspection via
query-qmp-schema will let you query which new commands ARE async. Or
existing commands will gain an optional parameter to opt-in to async
behavior for that command, defaulting to sync by default. Thus, an old
libvirt will never call an async command, and never notice the
difference, but a new libvirt that is aware of async commands will opt
in to the commands that it wants to use in an async manner.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
- Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread, (continued)
- Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread, Markus Armbruster, 2017/09/07
- Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread, Daniel P. Berrange, 2017/09/07
- Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread, Markus Armbruster, 2017/09/07
- Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread, Dr. David Alan Gilbert, 2017/09/07
- Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread, Markus Armbruster, 2017/09/07
- Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread, Dr. David Alan Gilbert, 2017/09/07
- Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread, Daniel P. Berrange, 2017/09/07
- Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread,
Eric Blake <=
Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread, Stefan Hajnoczi, 2017/09/06
- Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread, Dr. David Alan Gilbert, 2017/09/06
- Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread, Peter Xu, 2017/09/07
- Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread, Stefan Hajnoczi, 2017/09/07
- Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread, Dr. David Alan Gilbert, 2017/09/07
- Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread, Stefan Hajnoczi, 2017/09/07
- Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread, Peter Xu, 2017/09/07
- Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread, Stefan Hajnoczi, 2017/09/07
- Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread, Dr. David Alan Gilbert, 2017/09/07
- Re: [Qemu-devel] [RFC v2 0/8] monitor: allow per-monitor thread, Stefan Hajnoczi, 2017/09/07