On Tue, Mar 8, 2022 at 1:35 AM Peter Maydell <peter.mayd...@linaro.org> wrote: > > 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.
Well, I don't think so. main no longer calls back QEMU code (and it should never do so in my opinion). > 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. Basically NSView is the only thing prohibited from calling from another thread so it shouldn't be a problem. Regards, Akihiko Odaki > > thanks > -- PMM