add 18th iteration of classifier

1 files changed, 37 insertions, 0 deletions

diff --git a/results/classifier/118/none/2676 b/results/classifier/118/none/2676
new file mode 100644
index 000000000..ab150ee45
--- /dev/null
+++ b/results/classifier/118/none/2676
@@ -0,0 +1,37 @@
+graphic: 0.799
+device: 0.733
+vnc: 0.654
+socket: 0.633
+network: 0.557
+kernel: 0.552
+ppc: 0.524
+risc-v: 0.513
+files: 0.506
+architecture: 0.505
+TCG: 0.503
+PID: 0.503
+debug: 0.496
+VMM: 0.483
+register: 0.481
+semantic: 0.477
+performance: 0.476
+permissions: 0.413
+arm: 0.375
+mistranslation: 0.370
+boot: 0.345
+i386: 0.277
+assembly: 0.266
+hypervisor: 0.224
+user-level: 0.214
+peripherals: 0.197
+x86: 0.168
+KVM: 0.122
+virtual: 0.087
+
+GTK+ UI has serious problems on macOS hosts
+Description of problem:
+The GTK+ UI simply does not work on macOS at this stage. One major reason is that there does not appear to be any regular polling of the (macOS) UI event loop. The Cocoa back-end for GTK [sets a custom event polling function in GLib's event handler](https://gitlab.gnome.org/GNOME/gtk/-/blob/main/gdk/macos/gdkmacoseventsource.c?ref_type=heads#L1089) but Qemu never actually calls GLib/GTK's event polling.
+
+Thanks to @bonzini for discovering this as part of a [discussion on a patch generalising runloop event handling on macOS](https://patchew.org/QEMU/20241113142343.40832-1-phil@philjordan.eu/20241113142343.40832-2-phil@philjordan.eu/#CABgObfat1JwiBFNKHK6wwMkW5kgaqZfKJa=rW._5F9VvEdMWJR75A@mail.gmail.com).
+
+There is also a reasonable chance that QEMU might not reliably call GTK+ functions from the main thread (thread 0), which causes problems when GTK then calls through to the native Cocoa APIs which must be called from thread 0.