On Mon, Jul 29, 2013 at 04:08:34PM +0800, Wenchao Xia wrote: > > Now that aio_poll() users check their termination condition themselves, > > it is no longer necessary to call .io_flush() handlers. > > > > The behavior of aio_poll() changes as follows: > > > > 1. .io_flush() is no longer invoked and file descriptors are *always* > > monitored. Previously returning 0 from .io_flush() would skip this file > > descriptor. > > > > Due to this change it is essential to check that requests are pending > > before calling qemu_aio_wait(). Failure to do so means we block, for > > example, waiting for an idle iSCSI socket to become readable when there > > are no requests. Currently all qemu_aio_wait()/aio_poll() callers check > > before calling. > > > > 2. aio_poll() now returns true if progress was made (BH or fd handlers > > executed) and false otherwise. Previously it would return true whenever > > 'busy', which means that .io_flush() returned true. The 'busy' concept > > no longer exists so just progress is returned. > > > > Due to this change we need to update tests/test-aio.c which asserts > > aio_poll() return values. Note that QEMU doesn't actually rely on these > > return values so only tests/test-aio.c cares. > > > > Note that ctx->notifier, the EventNotifier fd used for aio_notify(), is > > now handled as a special case. This is a little ugly but maintains > > aio_poll() semantics, i.e. aio_notify() does not count as 'progress' and > > aio_poll() avoids blocking when the user has not set any fd handlers yet. > > > I guess the goal is, distinguish qemu's internal used fd, with the > real meaningful external fd such as socket?
Exactly, the AioContext's own internal EventNotifier should not count. For example, aio_poll() must not block if the user has not added any AioHandlers yet. > How about distinguish them with different GSource? AioContext itself is designed as a GSource. Internally it does not use GSource or the glib event loop. Introducing the glib event loop here would be a big change. I hope in the future we can unify main-loop.c and AioContext. At that point we might operate on GSources. Stefan
