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

[Akihiko Odaki]

On Tue, Mar 8, 2022 at 1:14 AM Peter Maydell <peter.maydell@linaro.org> wrote:
>
> On Mon, 7 Mar 2022 at 15:34, Akihiko Odaki <akihiko.odaki@gmail.com> wrote:
> >
> > On 2022/03/08 0:10, Paolo Bonzini wrote:
> > > Simplify the initialization dance by running qemu_init() in the main
> > > thread before the Cocoa event loop starts.  The cocoa_display_init()
> > > code that is post-applicationDidFinishLaunching: moves to the
> > > application delegate itself, and the secondary thread only runs
> > > the rest of qemu_main(), namely qemu_main_loop() and qemu_cleanup().
> > >
> > > This fixes a case where addRemovableDevicesMenuItems() calls
> > > qmp_query_block() while expecting the main thread to still hold
> > > the BQL.  The newly-introduced assertions in the block layer
> > > complain about this.
> >
> > Hi,
> >
> > Thanks for this interesting suggestion. However I don't think this
> > improves the situation much. The main contribution of this change is
> > that elimination of display_init_sem but it is still necessary for
> > command line usage of the executable.
>
> 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".
>
> thanks
> -- PMM

The current cocoa.m somehows calls back into QEMU code in main, but
that is not necessary as demonstrated in:
20220307134946.61407-1-akihiko.odaki@gmail.com/">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:].

Regards,
Akihiko Odaki