From: Paolo Bonzini <pbonzini@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: lersek@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com,
rjones@redhat.com
Subject: Re: [Qemu-devel] [PATCH] AioContext: fix broken ctx->dispatching optimization
Date: Thu, 16 Jul 2015 00:59:35 +0200 [thread overview]
Message-ID: <55A6E5D7.8000204@redhat.com> (raw)
In-Reply-To: <20150715201435.GF3582@noname.redhat.com>
On 15/07/2015 22:14, Kevin Wolf wrote:
> > index 233d8f5..ae7c6cf 100644
> > --- a/aio-win32.c
> > +++ b/aio-win32.c
> > @@ -318,11 +313,11 @@ bool aio_poll(AioContext *ctx, bool blocking)
> > first = true;
> >
> > /* wait until next event */
> > - while (count > 0) {
> > + do {
> > HANDLE event;
> > int ret;
> >
> > - timeout = blocking
> > + timeout = blocking && !have_select_revents
> > ? qemu_timeout_ns_to_ms(aio_compute_timeout(ctx)) : 0;
> > if (timeout) {
> > aio_context_release(ctx);
>
> Here I'm not sure why you switched to a do..while loop? It's not obvious
> to me how the change from aio_set_dispatching() to ctx->notify_me is
> related to this.
I sort of expected a reviewer to ask me about this change. I would have
explained this in the commit message, but it was already long enough. :)
The count on entry is never zero, because the ctx->notifier is always
registered.
I changed the while to do...while so that it's obvious that
ctx->notify_me is always decremented.
In retrospect I could have added simply
/* ctx->notifier is always registered. */
assert(count > 0);
above the "do".
> With this information, I understand that what has changed is that the
> return value of g_main_context_iteration() changes from true before this
> patch (had the aio_notify() from aio_set_fd_handler() pending) to false
> after the patch (aio_notify() doesn't inject an event any more).
>
> This should mean that like above we can assert that the first iteration
> returns false, i.e. reverse the assertion (and indeed, with this
> change the test still passes for me).
I was a bit undecided about this. In the end I decided that the calls
to aio_poll/g_main_context_iteration were just to put the AioContext in
a known state, and the assertions on the return value of g_assert were
not really important. For this reason, the while loop seemed to express
the intentions best, and I made it consistent between the AioContext and
GSource cases.
Paolo
next prev parent reply other threads:[~2015-07-15 22:59 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-15 17:13 [Qemu-devel] [PATCH] AioContext: fix broken ctx->dispatching optimization Paolo Bonzini
2015-07-15 18:00 ` Laszlo Ersek
2015-07-15 20:14 ` Kevin Wolf
2015-07-15 22:59 ` Paolo Bonzini [this message]
2015-07-16 9:14 ` Kevin Wolf
2015-07-16 9:34 ` Paolo Bonzini
2015-07-16 5:29 ` Fam Zheng
2015-07-16 9:14 ` Paolo Bonzini
2015-07-16 9:16 ` Stefan Hajnoczi
2015-07-16 10:17 ` Stefan Hajnoczi
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=55A6E5D7.8000204@redhat.com \
--to=pbonzini@redhat.com \
--cc=kwolf@redhat.com \
--cc=lersek@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=rjones@redhat.com \
--cc=stefanha@redhat.com \
/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).