On Sat, May 31, 2014 at 10:24:47PM +0200, Max Reitz wrote: > On 31.05.2014 20:43, Max Reitz wrote: > >[snip] > > > >However, if bs_aio_detach() is called from a different thread than the > >old AioContext is running in, we may still have coroutines running for > >which we should wait before returning from bs_aio_detach(). > > After re-reading Stefan's RFC and the AIO locking code, would it suffice to > call aio_context_acquire() and aio_context_release() on the old AioContext > at the end of bs_aio_detach() to ensure all coroutines are settled? If not, > I guess I have to wait until the coroutine variables are set to NULL (which > indicates they have completely finished execution; however, this is not > actually necessary and might lead to an infinite loop if the block driver > keeps yielding due to some condition related to the AioContext switch), or I > really have to switch the existing coroutines to the new AioContext while > they are running. Doing this from the outside will probably be even messier > than it would already be from the inside, so I sure hope to be able to avoid > this…
I think you don't need to worry about this at all. bdrv_set_aio_context() is always invoked with the QEMU global mutex held. Regarding switching a coroutine from one AioContext to another (possibly in another thread), I've implemented it but it's a little involved (complex and slow). Let's avoid it, if possible. I also lost the patch during the great "make distclean twice deletes .git/" fiasco of 2014 so would need to reimplement it :). Stefan