On Thu, 05/28 14:01, Paolo Bonzini wrote: > > > On 28/05/2015 13:49, Fam Zheng wrote: > > On Thu, 05/28 13:19, Paolo Bonzini wrote: > >> > >> > >> On 28/05/2015 13:16, Fam Zheng wrote: > >>>> On 28/05/2015 03:46, Fam Zheng wrote: > >>>>> The main context uses iohandler and aio_dispatch, neither calls > >>>>> aio_set_dispatching(). However, if we have [2], they can be changed to > >>>>> aio_poll(), then would this idea work? > >>>> > >>>> I think it's a bad idea to handle aio_poll for context B in a different > >>>> way, just because you have an outer aio_poll for context A... > >>> > >>> But we already do something similar: ignoring slirp, main_loop_wait() is > >>> like > >>> an iothread aio_poll() without the "outermost differentiation", while the > >>> current aio_poll() in bdrv_drain() is roughly "main_loop_wait() minus > >>> iohandlers". > >> > >> Right, but the two sets of iohandlers are stored in different places, so > >> it's obvious that you don't execute all of them. On the other hand, > >> examining global state in aio_poll is really bad. > >> > > > > OK. > > > > Would moving the ioeventfds to a new top level aio_loop_wait() be any > > better? > > That way no global state is needed. > > If we need pause/resume anyway due to block/mirror.c's use of > block_job_defer_to_main_loop, I think this is not a problem anymore? >
I also hope to dedup the iohandler code with async.c, on top of [2]; and in the longer term, convert slirp to use AioContext API too, so that all *_pollfds_fill() will not be necessary - the whole event loop goes epoll style. Fam
