Il 09/08/2013 17:09, Stefan Hajnoczi ha scritto: >> Perhaps, but do we really need it to work outside AioContexts? Using a >> second AioContext for bottom halves has been mentioned for a while. It >> would fix issues where a bottom half runs spuriously before QEMU starts, >> just because something uses qemu_aio_wait(). Extending the same >> approach to timers is natural. >> >> At some point Stefan was planning to add a per-BlockDriverState >> AioContext. Once that is done, using two different AioContext for >> "default block layer context" and "default main loop" context would be >> very easily done. > > The model I'm going for is that the user can configure how many event > loop threads to use. Then they can bind a -drive to a specific event > loop thread and it will operate in that AioContext.
Yes, this is really what I meant. I wasn't sure exactly how to describe it. In any case, it is not really related to nested event loops. It even seems like an extension of what I'm asking Alex to do. In principle you could have many AioContexts (plus the one for qemu_new_timer aka qemu_timer_new) but put all of them in the main iothread. Paolo > So it isn't quite a per-BDS AioContext model but perhaps I'll hit > something which does require per-BDS AioContexts.
