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

[Paolo Bonzini]

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

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