qemu-riscv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: BALATON Zoltan
Subject: Re: [PATCH v8 01/15] ui & main loop: Redesign of system-specific main thread event handling
Date: Mon, 11 Nov 2024 13:41:04 +0100 (CET)

On Mon, 11 Nov 2024, Phil Dennis-Jordan wrote:
On Mon, 11 Nov 2024 at 10:08, Daniel P. Berrangé <berrange@redhat.com>
wrote:

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.


Agreed - I'm now more confused than ever though because
https://gitlab.com/qemu-project/qemu/-/issues/2539 sort of implies that
Philippe has previously been using it successfully. Or perhaps this was
created in response to https://gitlab.com/qemu-project/qemu/-/issues/2515 ?
But it seems like even the SDL implementation isn't perfect:
https://gitlab.com/qemu-project/qemu/-/issues/2537

Basically, it seems like Qemu's UI threading on macOS is currently a bit of
a mess, except in the Cocoa UI.

Maybe it worked with older MacOS X releases but broke around the same time when commit 5588840ff77800 was needed to fix the cocoa UI? Maybe gtk needs a similar fix or whatever cocoa was changed to use since somewhere in gtk or QEMU?

Also I find it strange to require UI backends to NULL init a global. If the cocoa UI is the only one that needs it could that also set it instead of doing it in /system? That would also confine macOS specific code to cocoa.m and the other UIs would not need any change that way.

Regards,
BALATON Zoltan

reply via email to

[Prev in Thread] Current Thread [Next in Thread]