Re: [PATCH v8 01/15] ui & main loop: Redesign of system-specific main thread event handling

["Daniel P. Berrangé" <berrange@redhat.com>]

On Sun, Nov 10, 2024 at 08:08:16AM +0100, Phil Dennis-Jordan wrote:
> On Sun 10. Nov 2024 at 08:01, Akihiko Odaki <akihiko.odaki@daynix.com>
> wrote:
> 
> > On 2024/11/08 23:46, Phil Dennis-Jordan wrote:
> > > macOS's Cocoa event handling must be done on the initial (main) thread
> > > of the process. Furthermore, if library or application code uses
> > > libdispatch, the main dispatch queue must be handling events on the main
> > > thread as well.
> > >
> > > So far, this has affected Qemu in both the Cocoa and SDL UIs, although
> > > in different ways: the Cocoa UI replaces the default qemu_main function
> > > with one that spins Qemu's internal main event loop off onto a
> > > background thread. SDL (which uses Cocoa internally) on the other hand
> > > uses a polling approach within Qemu's main event loop. Events are
> > > polled during the SDL UI's dpy_refresh callback, which happens to run
> > > on the main thread by default.
> >
> > GTK should also do the same as SDL and requires treatment; I forgot to
> > note that in previous reviews.
> 
> 
> Although it‘s possible to build Qemu with GTK support enabled on macOS,
> that UI doesn’t actually work on macOS at all, and apparently hasn’t been
> supported since 2018, see:
> https://stackoverflow.com/a/51474795
> 
> I don’t think there’s any point making adjustments to the GTK code by
> guessing what might be needed if someone did fix that to work with macOS at
> some point.

If we don't support GTK on macOS, then we should update meson.build
to actively prevent users enabling GTK on macOS builds, rather than
letting them suffer random runtime crashes.


With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|