On Tue, Mar 8, 2022 at 1:14 AM Peter Maydell <peter.mayd...@linaro.org> wrote: > > On Mon, 7 Mar 2022 at 15:34, Akihiko Odaki <akihiko.od...@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: 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:]. Regards, Akihiko Odaki
