Re: [Qemu-devel] [RFC PATCH 00/17] Support for multiple "AIO contexts"

[Paolo Bonzini]

Il 26/09/2012 16:31, Kevin Wolf ha scritto:

>>> In fact, after removing io_flush, I don't really see what makes AIO
>>> fd handlers special any more.
>>
>> Note that while the handlers aren't that special indeed, there is still
>> some magic because qemu_aio_wait() bottom halves.
> 
> Do you mean the qemu_bh_poll() call? But the normal main loop does the
> same, so I don't see what would be special about it.

That's an abstraction leakage, IMHO.  After this series the normal main
loop does not need anymore to call bottom halves.

(Most usage of bottom halves in hw/* is pointless and also falls under
the category of leaked abstractions.  The other uses could also in
principle be called at the wrong time inside monitor commands.  Many
would be served better by a thread pool if it wasn't for our beloved big
lock).

>>> qemu_aio_wait() only calls these handlers, but would it do any harm if
>>> we called all fd handlers?
>>
>> Unfortunately yes.  You could get re-entrant calls from the monitor
>> while a monitor command drains the AIO queue for example.
> 
> Hm, that's true... Who's special here - is it the block layer or the
> monitor? I'm not quite sure. If it's the monitor, maybe we should plan
> to change that sometime when we have some spare time... ;-)

It feels like it's the monitor.  But I think in general it is better if
as little QEMU infrastructure as possible is used by the block layer,
because you end up with impossibly-knotted dependencies.  Using things
such as GSource to mediate between the block layer and everything else
is also better with an eye to libqblock.

Also, consider that under Windows there's a big difference: after this
series, qemu_aio_wait() only works with EventNotifiers, while
qemu_set_fd_handler2 only works with sockets.  Networked block drivers
are disabled for Windows by these patches, there's really no way to move
forward without sacrificing them.

Paolo