Re: [Qemu-devel] [RFC] [PATCHv10 00/31] aio / timers: Add AioContext timers and use ppoll

[Alex Bligh]

Jan,

On 13 Aug 2013, at 14:25, Jan Kiszka wrote:

> To my understanding, the use case behind the current behavior is
> qemu_aio_wait() which is only supposed to block when there are pending
> requests for the main aio context. We should be able to address this
> scenarios also in a different way. I would definitely prefer to not
> depend on that hack above.

I don't *think* so. If I'm right the problem is line 233 of
aio-posix.c (and similar in the windows variant):

    /* No AIO operations?  Get us out of here */
    if (!busy) {
        return progress;
    }

    ... do qemu_poll_ns ...

busy is set to true if there are any FDs for which ->flush
is true and ->io_flush() returns non-zero.

I think this should instead be looking the equivalent of
FD_ISSET across all FDs (read and write) and the blocking flag.
IE if blocking is set to true, then it should ALWAYS do
qemu_poll_ns, lest it busyloop rather than wait for the
next timer expiry.

More here:
  https://lists.gnu.org/archive/html/qemu-devel/2013-07/msg03950.html

I'm not very happy with this logic (but it's the same as before),
and I note Stefan removes the horrible busy flag in this
series:
  http://lists.nongnu.org/archive/html/qemu-devel/2013-07/msg00092.html

In this case, I'm not sure it makes a great deal of difference in
practice as you'll need an eventfd or something similar to signal
to the thread that it should exit, I presume.

-- 
Alex Bligh