On Thu, 14 Nov 2024 at 14:27, Paolo Bonzini <pbonz...@redhat.com> wrote:
> On Thu, Nov 14, 2024 at 11:32 AM Phil Dennis-Jordan <li...@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: https://gitlab.com/qemu-project/qemu/-/issues/2676 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. > Sorry, this was in reference to Daniel Berrangé's comment on this related bug: https://gitlab.com/qemu-project/qemu/-/issues/2537#note_2203183775 (QEMU's SDL UI also falls afoul of macOS's threading requirements in some specific cases.)
