[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v6 06/18] aio: stop using .io_flush()
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [PATCH v6 06/18] aio: stop using .io_flush() |
Date: |
Mon, 29 Jul 2013 16:32:10 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
- Re: [Qemu-devel] [PATCH v6 03/18] dataplane/virtio-blk: check exit conditions before aio_poll(), (continued)
- [Qemu-devel] [PATCH v6 01/18] block: ensure bdrv_drain_all() works during bdrv_delete(), Stefan Hajnoczi, 2013/07/25
- [Qemu-devel] [PATCH v6 08/18] block/gluster: drop qemu_gluster_aio_flush_cb(), Stefan Hajnoczi, 2013/07/25
- [Qemu-devel] [PATCH v6 15/18] dataplane/virtio-blk: drop flush_true() and flush_io(), Stefan Hajnoczi, 2013/07/25
- [Qemu-devel] [PATCH v6 17/18] tests: drop event_active_cb(), Stefan Hajnoczi, 2013/07/25
- [Qemu-devel] [PATCH v6 18/18] aio: drop io_flush argument, Stefan Hajnoczi, 2013/07/25