Re: [RFC uncompiled PATCH] cocoa: run qemu_init in the main thread

[Akihiko Odaki <akihiko.odaki@gmail.com>]

On Tue, Mar 8, 2022 at 1:35 AM Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Mon, 7 Mar 2022 at 16:27, Akihiko Odaki <akihiko.odaki@gmail.com> wrote:
> > On Tue, Mar 8, 2022 at 1:14 AM Peter Maydell <peter.maydell@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.odaki@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