diff options
author | Stefan Hajnoczi <stefanha@redhat.com> | 2018-02-16 16:50:12 +0000 |
---|---|---|
committer | Kevin Wolf <kwolf@redhat.com> | 2018-03-02 18:39:07 +0100 |
commit | 7719f3c968c59e1bcda7e177679dc765b59e578f (patch) | |
tree | 9a712da144732941764479a42272a493098339f7 /hw/9pfs | |
parent | d2b63ba8dd20c1091b3f1033e6a95ef95b18149d (diff) | |
download | qemu-7719f3c968c59e1bcda7e177679dc765b59e578f.zip qemu-7719f3c968c59e1bcda7e177679dc765b59e578f.tar.gz qemu-7719f3c968c59e1bcda7e177679dc765b59e578f.tar.bz2 |
block: extract AIO_WAIT_WHILE() from BlockDriverState
BlockDriverState has the BDRV_POLL_WHILE() macro to wait on event loop
activity while a condition evaluates to true. This is used to implement
synchronous operations where it acts as a condvar between the IOThread
running the operation and the main loop waiting for the operation. It
can also be called from the thread that owns the AioContext and in that
case it's just a nested event loop.
BlockBackend needs this behavior but doesn't always have a
BlockDriverState it can use. This patch extracts BDRV_POLL_WHILE() into
the AioWait abstraction, which can be used with AioContext and isn't
tied to BlockDriverState anymore.
This feature could be built directly into AioContext but then all users
would kick the event loop even if they signal different conditions.
Imagine an AioContext with many BlockDriverStates, each time a request
completes any waiter would wake up and re-check their condition. It's
nicer to keep a separate AioWait object for each condition instead.
Please see "block/aio-wait.h" for details on the API.
The name AIO_WAIT_WHILE() avoids the confusion between AIO_POLL_WHILE()
and AioContext polling.
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to 'hw/9pfs')
0 files changed, 0 insertions, 0 deletions