qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Question on aio_poll


From: Alex Bligh
Subject: [Qemu-devel] Question on aio_poll
Date: Sat, 20 Jul 2013 14:14:43 +0100

As part of adding timer operations to aio_poll and a clock to AioContext, I
am trying to figure out a couple of points on how aio_poll works. This
primarily revolves around the flag busy.

Firstly, at the end of aio_poll, it has
    assert(progress || busy);

This assert in fact checks nothing, because before the poll (20 lines or
so higher), it has
    if (!busy) {
        return progress;
    }

and as 'busy' is not altered, busy must be true at the assert.

Is this in fact meant to be checking that we have made progress if aio_poll
is called blocking? IE assert(progress || !blocking) ?

Secondly, the tests I am writing for the timer fail because g_poll is
not called, because busy is false. This is because I haven't got an
fd set up. But in the instance where aio_poll is called with blocking=true
and there are no fd's to wait on, surely aio_poll should either hang
indefinitely or (perhaps better) assert, rather than return immediately
which is a recipe for an unexpected busywait? If I have timers, it should
be running those timers rather than returning.

Thirdly, I don't quite understand how/why busy is being set. It seems
to be set if the flush callback returns non-zero. That would imply (I think)
the fd handler has something to write. But what if it is just interested
in any data to read that is available (and never writes)? If this is the
only fd aio_poll has, it would appear it never polls.

When adapting this for timers, I think it should be returning true only
if a an AIO dispatch did something, or a BH was executed, or a timer ran.
Specifically if the poll simply times out, it should not be returning
true unless a timer ran. Correct?

--
Alex Bligh



reply via email to

[Prev in Thread] Current Thread [Next in Thread]