Il 07/12/2012 07:06, Stefan Hajnoczi ha scritto: > BTW I should go into slightly more detail about why I stopped short of > implementing the notify+join approach. > > notify+join means stopping the event loop and data plane thread so > that the caller is sure that virtio-blk-data-plane is quiesced. > > Unfortunately this doesn't map nicely to bdrv_drain_all() where the > caller has the global mutex, quiesces I/O, and then performs a critical > operation. I/O resumes after the caller returns or releases the global > mutex: > > bdrv_drain_all(); > critical_operation(); > return; > /* now it's okay to process I/O again */ > > We cannot use notify+join here because bdrv_drain_all() would stop the > data plane thread but nothing restarts it!
That's true. The solution here for AioContext would be to run the event loop in the context of the thread that is calling bdrv_drain_all(). But you do not need bdrv_drain_all() right now, and the event loop would be rewritten anyway to use AioContext, so the lack of "resume" is not a problem for now IMHO. > Perhaps we'd need a "resume" call after the critical operation so that > the data plane thread is restarted - but this sounds invasive and is a > departure from how existing I/O and emulated devices work. The problem was more about the possible race in the draining of requests, but it's okay to tackle it later. Paolo
