Re: [Qemu-devel] [PATCH v6 06/18] aio: stop using .io_flush()

[Stefan Hajnoczi <stefanha@gmail.com>]

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