All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-devel@nongnu.org, marcandre.lureau@gmail.com,
	armbru@redhat.com, qemu-block@nongnu.org, dgilbert@redhat.com
Subject: Re: [PATCH v7 00/13] monitor: Optionally run handlers in coroutines
Date: Mon, 28 Sep 2020 09:46:09 +0100	[thread overview]
Message-ID: <20200928084609.GC43571@stefanha-x1.localdomain> (raw)
In-Reply-To: <20200925171541.GK5731@linux.fritz.box>

[-- Attachment #1: Type: text/plain, Size: 1848 bytes --]

On Fri, Sep 25, 2020 at 07:15:41PM +0200, Kevin Wolf wrote:
> Am 10.09.2020 um 15:24 hat Stefan Hajnoczi geschrieben:
> > On Wed, Sep 09, 2020 at 05:11:36PM +0200, Kevin Wolf wrote:
> > > Some QMP command handlers can block the main loop for a relatively long
> > > time, for example because they perform some I/O. This is quite nasty.
> > > Allowing such handlers to run in a coroutine where they can yield (and
> > > therefore release the BQL) while waiting for an event such as I/O
> > > completion solves the problem.
> > > 
> > > This series adds the infrastructure to allow this and switches
> > > block_resize to run in a coroutine as a first example.
> > > 
> > > This is an alternative solution to Marc-André's "monitor: add
> > > asynchronous command type" series.
> > 
> > Please clarify the following in the QAPI documentation:
> >  * Is the QMP monitor suspended while the command is pending?
> 
> Suspended as in monitor_suspend()? No.
> 
> >  * Are QMP events reported while the command is pending?
> 
> Hm, I don't know to be honest. But I think so.
> 
> Does it matter, though? I don't think events have a defined order
> compared to command results, and the client can't respond to the event
> anyway until the current command has completed.

You're right, I don't think it matters because the client must expect
QMP events at any time.

I was trying to understand the semantics of coroutine monitor commands
from two perspectives:

1. The QMP client - do coroutine commands behave differently from
   non-coroutine commands? I think the answer is no. The monitor will
   not process more commands until the coroutine finishes?

2. The command implementation - which thread does the coroutine run in?
   I guess it runs in the main loop thread with the BQL and the
   AioContext acquired?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2020-09-28  8:47 UTC|newest]

Thread overview: 62+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-09 15:11 [PATCH v7 00/13] monitor: Optionally run handlers in coroutines Kevin Wolf
2020-09-09 15:11 ` [PATCH v7 01/13] monitor: Add Monitor parameter to monitor_set_cpu() Kevin Wolf
2020-09-09 15:11 ` [PATCH v7 02/13] monitor: Add Monitor parameter to monitor_get_cpu_index() Kevin Wolf
2020-09-09 15:11 ` [PATCH v7 03/13] monitor: Use getter/setter functions for cur_mon Kevin Wolf
2020-10-02  7:51   ` Markus Armbruster
2020-09-09 15:11 ` [PATCH v7 04/13] hmp: Update current monitor only in handle_hmp_command() Kevin Wolf
2020-09-09 15:11 ` [PATCH v7 05/13] qmp: Assert that no other monitor is active Kevin Wolf
2020-09-09 15:11 ` [PATCH v7 06/13] qmp: Call monitor_set_cur() only in qmp_dispatch() Kevin Wolf
2020-09-14 15:10   ` Markus Armbruster
2020-09-25 15:13     ` Kevin Wolf
2020-09-28 11:42       ` Markus Armbruster
2020-09-28 14:30         ` Kevin Wolf
2020-09-30  9:26           ` Markus Armbruster
2020-09-30 11:29             ` Kevin Wolf
2020-09-30 13:14               ` Markus Armbruster
2020-09-30 14:00                 ` Kevin Wolf
2020-09-30 17:20                   ` Dr. David Alan Gilbert
2020-10-01 10:14                     ` Kevin Wolf
2020-10-01 16:00                       ` Markus Armbruster
2020-10-02  8:04                         ` Markus Armbruster
2020-09-09 15:11 ` [PATCH v7 07/13] monitor: Make current monitor a per-coroutine property Kevin Wolf
2020-09-14 15:11   ` Markus Armbruster
2020-09-25 15:23     ` Kevin Wolf
2020-09-28  7:47       ` Markus Armbruster
2020-09-28 10:42         ` Kevin Wolf
2020-09-28 12:21           ` Markus Armbruster
2020-10-02  7:53   ` Markus Armbruster
2020-09-09 15:11 ` [PATCH v7 08/13] qapi: Add a 'coroutine' flag for commands Kevin Wolf
2020-09-14 15:15   ` Markus Armbruster
2020-09-25 15:37     ` Kevin Wolf
2020-09-28  8:23       ` Markus Armbruster
2020-10-02  7:53   ` Markus Armbruster
2020-10-02  7:59   ` Markus Armbruster
2020-09-09 15:11 ` [PATCH v7 09/13] qmp: Move dispatcher to a coroutine Kevin Wolf
2020-09-14 15:30   ` Markus Armbruster
2020-09-25 15:38     ` Kevin Wolf
2020-09-28  8:24       ` Markus Armbruster
2020-10-02  8:01   ` Markus Armbruster
2020-09-09 15:11 ` [PATCH v7 10/13] hmp: Add support for coroutine command handlers Kevin Wolf
2020-09-16  9:46   ` Dr. David Alan Gilbert
2020-10-02  8:01   ` Markus Armbruster
2020-09-09 15:11 ` [PATCH v7 11/13] util/async: Add aio_co_reschedule_self() Kevin Wolf
2020-09-15 14:25   ` Stefan Hajnoczi
2020-10-02  8:01   ` Markus Armbruster
2020-09-09 15:11 ` [PATCH v7 12/13] block: Add bdrv_co_move_to_aio_context() Kevin Wolf
2020-09-15 14:31   ` Stefan Hajnoczi
2020-09-25 16:00     ` Kevin Wolf
2020-09-28  8:59       ` Stefan Hajnoczi
2020-09-28 10:21         ` Kevin Wolf
2020-09-09 15:11 ` [PATCH v7 13/13] block: Convert 'block_resize' to coroutine Kevin Wolf
2020-09-15 14:57   ` Stefan Hajnoczi
2020-09-25 16:07     ` Kevin Wolf
2020-09-28  9:05       ` Stefan Hajnoczi
2020-09-28 10:33         ` Kevin Wolf
2020-09-09 15:24 ` [PATCH v7 00/13] monitor: Optionally run handlers in coroutines no-reply
2020-09-10 13:24 ` Stefan Hajnoczi
2020-09-14 15:09   ` Markus Armbruster
2020-09-15 14:58     ` Stefan Hajnoczi
2020-09-25 17:15   ` Kevin Wolf
2020-09-28  8:46     ` Stefan Hajnoczi [this message]
2020-09-28  9:47       ` Kevin Wolf
2020-09-28  9:30     ` Markus Armbruster

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200928084609.GC43571@stefanha-x1.localdomain \
    --to=stefanha@redhat.com \
    --cc=armbru@redhat.com \
    --cc=dgilbert@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=marcandre.lureau@gmail.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.