On Wed, Mar 09, 2022 at 02:26:28PM +0100, Emanuele Giuseppe Esposito wrote: > Am 02/03/2022 um 10:47 schrieb Stefan Hajnoczi: > > On Tue, Mar 01, 2022 at 09:21:08AM -0500, Emanuele Giuseppe Esposito wrote: > >> Possible scenarios > >> ------------------- > >> Keeping in mind that we can only have an iothread and the main loop > >> draining on a certain node, we could have: > >> > >> main loop successfully drains and then iothread tries to drain: > >> impossible scenario, as iothread is already stopped once main > >> successfully drains. > >> > >> iothread successfully drains and then main loop drains: > >> should not be a problem, as: > >> 1) the iothread should be already "blocked" by its own drain > > > > Once drained_begin() returns in the IOThread, the IOThread can do > > anything it wants, including more submitting I/O. I don't consider that > > "blocked", so I'm not sure what this sentence means? > > > > The way the main loop thread protects itself against the IOThread is via > > the aio "external" handler concept and block job drain callbacks, which > > are activated by drained_begin(). They ensure that the IOThread will not > > perform further processing that submits I/O, but the IOThread code that > > invoked drained_begin() can still do anything it wants. > > As above I think that regardless on what the iothread is doing, once the > main loop has finished executing bdrv_drained_begin the iothread should > not be doing anything related to the nodes that have been drained.
I agree. What I wanted to highlight is that waiting for requests to complete is not what stops the IOThread, it's the "external" AIO handler mechanism. Stefan
signature.asc
Description: PGP signature
