Am 21.01.2022 um 18:05 hat Emanuele Giuseppe Esposito geschrieben: > When invoked from the main loop, this function is the same > as qemu_mutex_iothread_locked, and returns true if the BQL is held.
So its name is misleading because it doesn't answer the question whether we're in the main thread, but whethere we're holding the BQL (which is mostly equivalent to holding an AioContext lock, not being in the home thread of that AioContext). > When invoked from iothreads or tests, it returns true only > if the current AioContext is the Main Loop. > > This essentially just extends qemu_mutex_iothread_locked to work > also in unit tests or other users like storage-daemon, that run > in the Main Loop but end up using the implementation in > stubs/iothread-lock.c. > > Using qemu_mutex_iothread_locked in unit tests defaults to false > because they use the implementation in stubs/iothread-lock, > making all assertions added in next patches fail despite the > AioContext is still the main loop. > > Signed-off-by: Emanuele Giuseppe Esposito <eespo...@redhat.com> > Reviewed-by: Stefan Hajnoczi <stefa...@redhat.com> This adds a new function that is almost the same as an existing function, but the documentation is unclear when I should use one or the other. What are the use cases for the existing qemu_mutex_iothread_locked() stub where we rely on false being returned? If there aren't any, then maybe we should change the stub for that one instead of adding a new function that behaves the same in the system emulator and different only when it's stubbed out? Kevin
