On Thu, Nov 14, 2024 at 11:32 AM Phil Dennis-Jordan <lists@philjordan.eu> wrote:
>> I checked what GTK+ does and, either way, you have to create another
>> thread: timers are handled with a CFRunLoopTimer, but file descriptors
>> are polled in a separate thread and sent to the main thread with a
>> single CFRunLoopSource. It's a bit nicer that the main thread is in
>> charge, but it's more complex and probably slower too.
>
>
> Just to clarify: is this supposed to be happening inside the GTK+ library itself? i.e. GTK should spawn its own thread to poll file descriptors that are owned by GTK? (As opposed to the file descriptors used by QEMU's own event loop - what on Linux are eventfds, but on macOS I think are just pipes*.)
It's what I saw in the GTK+ source code.
https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gdk/macos/gdkmacoseventsource.c?ref_type=heads
> This doesn't describe what I'm seeing when I run with -display gtk on macOS. There's no extra thread created. There's a dock icon, but it's non-interactive ("Application not responding"), there aren't any menus, and there's no window. QEMU's own simulation is running in the background - I can reach a guest via the network. So I guess there's some function in GTK we're supposed to be calling that will make it crank the native event loop on macOS, but this isn't being done?
In theory it should work, with the event source added as soon as GTK+
is started... aha!
We do not use the GMainContext's poll_func, we use qemu_poll_ns.
That's the missing part: GDK replaces the poll_func with one that
calls nextEventMatchingMask:
https://gitlab.gnome.org/GNOME/gtk/-/blame/main/gdk/macos/gdkmacoseventsource.c?ref_type=heads#L767
Thanks for explaining. That makes sense - I was looking in the Qemu source for where exactly it was polling the GLib/GTK event handler, now I know why I couldn't find it. Tracing the poll_func setting, it looks like GTK expects g_main_context_iteration() to be called regularly, or the main thread needs to call and block inside g_main_loop_run.
But in QEMU it's not as easy a fix as just going ahead and doing one of those two things because QEMU semi-replicates the GLib poll function, and we can't use both at the same time. Right?
There could be more issues, but I think for now it's better to block
the GTK+ UI under macOS.
OK, I've created a new issue on GitLab where any further decision making and action can be tracked:
I'm not sure this patchset is the best place for a patch blocking GTK on macOS, especially if you want it in 9.2.
[...]
>> As long as it's clear that any handlers that go through the CFRunLoop
>> run outside the BQL, as is already the case for the Cocoa UI, I see no
>> problem with this approach.
>
> I'm not entirely sure what you're getting at here, to be honest. The UI thread can definitely not assume to be holding the BQL all the time; we'd have to treat it more like an AIOContext. It could pave the way towards putting the display and UI subsystems on their own AIOContext or AIOContext-like-thing, rather than hogging the BQL for expensive image operations.
Don't worry, I was mostly talking to myself... The UI thread, and more
specifically any handlers that are called from CFRunLoop instead of
QEMU's main loop, will have to use mutexes or bql_lock()/bql_unlock(),
like ui/cocoa.m already does.
In other words, code that interacts with Apple's paravirtualized
graphics needs to know if it runs from the CFRunLoop or from
qemu_main().
We already have extremely careful threading code in patch 02/15 for safely interfacing the threading models of the PV Graphics/libdispatch world and QEMU's world of BQL, AIOs, BHs, and so on.
> (*By the sound of it, Win32 has an all-UI-calls-on-one-thread requirement as well which we may be violating to some degree via the GTK and/or SDL backends as well; my adventures with Win32 are almost 20 years back now so I'm a bit out of the loop there.)
Hmm, no I don't remember anything like that for Windows but it's also
been many years for me.