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

[Peter Maydell <peter.maydell@linaro.org>]

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