From: "Marc-André Lureau" <marcandre.lureau@gmail.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>,
Gerd Hoffmann <kraxel@redhat.com>, QEMU <qemu-devel@nongnu.org>
Subject: Re: [PATCH v6 00/25] monitor: add asynchronous command type
Date: Tue, 7 Jan 2020 16:11:01 +0400 [thread overview]
Message-ID: <CAJ+F1CLocmL-9d06jsbfUFq1peV7w-Ho30vKnp7cVVk8jfXVnw@mail.gmail.com> (raw)
In-Reply-To: <20200107051728.GA4076@linux.fritz.box>
Hi
On Tue, Jan 7, 2020 at 9:17 AM Kevin Wolf <kwolf@redhat.com> wrote:
>
> Am 06.01.2020 um 19:21 hat Marc-André Lureau geschrieben:
> > > What my patch does is moving everything into a coroutine. This is wrong
> > > because not everything can be run in a coroutine, so it needs to be made
> > > optional (like you did with your async flag).
> >
> > "everything" is a bit too much ;) You proposal is to replace
> > qmp_dispatch_bh by a coroutine version (except for OOB commands). This
> > is nice because indeed, it allows to reenter the mainloop with a
> > simple yield in QMP commands. It is also simpler than my "async"
> > proposal, because some of the state is part of the coroutine, and
> > because it doesn't allow QMP commands concurrency (beside existing
> > OOB).
> >
> > Iow, coroutine (for async) + oob (for concurrency) make my proposal
> > kinda obsolete. I can only regret that a simple callback-based
> > solution looked simpler to me than one that mixes both threads &
> > coroutines, but I don't mind if everybody likes it better :) I can
> > definitely see the point for block commands, which rely on coroutines
> > anyway, and qemu is already that complex in general.
>
> Callbacks are indeed simple enough for implementing the infrastructure,
> but for the users they only look simple as long as they do trivial
> things. :-)
>
> Anyway, now that you have seen my POC hack, do you agree that this
> should help solving the screendump problem, too?
Yes, and I will work on it as soon as you have a working patch series
or branch :)
>
> > > The problem isn't with completely coroutine-unaware code, though: That
> > > one would just work, even if not taking advantage from the coroutine. A
> > > potential problem exists with code that behaves differently when run in
> > > a coroutine or outside of coroutine context (generally by checking
> > > qemu_in_coroutine())), or calls of coroutine-unaware code into such
> > > functions.
> > >
> > > Running some command handlers outside of coroutine context wouldn't be
> > > hard to add to my patch (basically just a BH), but I haven't looked into
> > > the QAPI side of making it an option.
> >
> > Yes, I think we should have a 'coroutine': true, for commands that
> > should be run with a coroutine.
> >
> > Or perhaps replace existing allow-oob with 'dispatch':
> > - 'bh' (default)
> > - 'coroutine'
> > - 'allow-oob' (oob + bh fallback, since oob don't have coroutine - at
> > this point)
>
> If it's "at this point", then making it two separate bools would make
> more sense. But I seem to remember that OOB handlers are fundamentally
> not supposed to block, so coroutine support would be pointless for them
> and an enum could work.
I think so too
>
> I'll defer to Markus on this one.
Yup, Markus should take a look at your proposal and give some
guidance. And hopefully, it won't take >2y.
>
> > Your patch looks quite good to me, but make check hangs. Have you
> > looked at it?
>
> I'm not sure if I was looking at some qemu-iotests cases or make check,
> but yes, I did see a hang. My case was a QMP command that just doesn't
> work correctly inside a coroutine without modifications, so requiring
> 'coroutine': true would fix it.
ok, then I suggest you do a "minimal" patch series that works.
thanks!
--
Marc-André Lureau
next prev parent reply other threads:[~2020-01-07 12:20 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-08 15:00 [PATCH v6 00/25] monitor: add asynchronous command type Marc-André Lureau
2019-11-08 15:00 ` [PATCH v6 01/25] qmp: constify QmpCommand and list Marc-André Lureau
2019-11-08 16:50 ` Damien Hedde
2020-02-17 11:47 ` Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 02/25] json-lexer: make it safe to call destroy multiple times Marc-André Lureau
2019-11-08 16:04 ` Damien Hedde
2019-11-08 15:01 ` [PATCH v6 03/25] qmp: add QmpSession Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 04/25] QmpSession: add a return callback Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 05/25] QmpSession: add json parser and use it in qga Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 06/25] monitor: use qmp session to parse json feed Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 07/25] qga: simplify dispatch_return_cb Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 08/25] QmpSession: introduce QmpReturn Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 09/25] qmp: simplify qmp_return_error() Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 10/25] QmpSession: keep a queue of pending commands Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 11/25] QmpSession: return orderly Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 12/25] qmp: introduce asynchronous command type Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 13/25] scripts: learn 'async' qapi commands Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 14/25] qmp: add qmp_return_is_cancelled() Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 15/25] console: add graphic_hw_update_done() Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 16/25] ppm-save: pass opened fd Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 17/25] ui: add pixman image g_autoptr support Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 18/25] object: add " Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 19/25] screendump: replace FILE with QIOChannel and fix close()/qemu_close() Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 20/25] osdep: add qemu_unlink() Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 21/25] screendump: use qemu_unlink() Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 22/25] console: make screendump asynchronous Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 23/25] monitor: start making qmp_human_monitor_command() asynchronous Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 24/25] monitor: teach HMP about asynchronous commands Marc-André Lureau
2019-11-08 15:01 ` [PATCH v6 25/25] hmp: call the asynchronous QMP screendump to fix outdated/glitches Marc-André Lureau
2019-12-13 16:03 ` [PATCH v6 00/25] monitor: add asynchronous command type Kevin Wolf
2019-12-13 16:28 ` Marc-André Lureau
2019-12-16 12:07 ` Kevin Wolf
2020-01-06 18:21 ` Marc-André Lureau
2020-01-07 5:17 ` Kevin Wolf
2020-01-07 12:11 ` Marc-André Lureau [this message]
2020-01-13 15:58 ` Markus Armbruster
2020-01-13 16:54 ` Kevin Wolf
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=CAJ+F1CLocmL-9d06jsbfUFq1peV7w-Ho30vKnp7cVVk8jfXVnw@mail.gmail.com \
--to=marcandre.lureau@gmail.com \
--cc=armbru@redhat.com \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).