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 There could be more issues, but I think for now it's better to block the GTK+ UI under macOS. [...] >> 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(). > (*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. Paolo
