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 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.