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
