On Mon, 7 Mar 2022 at 16:27, Akihiko Odaki <akihiko.od...@gmail.com> wrote: > On Tue, Mar 8, 2022 at 1:14 AM Peter Maydell <peter.mayd...@linaro.org> wrote: > > The main benefit of Paolo's suggestion from my point of view is > > that it entirely eliminates the odd situation where cocoa.m wants to > > make calls back into QEMU code where it does not itself hold > > the iothread lock in the current thread, but instead knows that > > some other thread does and is waiting for it. Instead we end up > > with a much more straightforward situation of "every time we > > call into QEMU code we hold the iothread lock directly ourselves".
> The current cocoa.m somehows calls back into QEMU code in main, but > that is not necessary as demonstrated in: > https://patchew.org/QEMU/20220307134946.61407-1-akihiko.od...@gmail.com/ > > With the code is moved, it becomes only a difference of the place > where the code without iothread is located, in main or in > [-QemuCocoaAppController applicationDidFinishLaunching:]. That series doesn't remove the general design that has quite a bit of "we know some other thread holds the lock and waits for us" code. It also gives us the opposite problem that we're now calling a lot of Cocoa APIs from something other than the main Cocoa thread. thanks -- PMM
