[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH] Fix for crashes and non-responsive UI on macOS
From: |
Gerd Hoffmann |
Subject: |
Re: [Qemu-devel] [PATCH] Fix for crashes and non-responsive UI on macOS Mojave |
Date: |
Thu, 22 Nov 2018 08:32:02 +0100 |
User-agent: |
NeoMutt/20180716 |
Hi,
> Something somewhere in this call chain should have taken
> the iothread lock, I assume, but I'm not sure where.
>
> Gerd -- what are the rules of the UI subsystem regarding
> multiple threads, and what threads are allowed to call
> UI functions like qemu_input_event_send_key_qcode(),
> from which threads, and whether they need to eg hold
> the iothread lock when they do so? There's no
> documentation on these functions in include/ui/input.h.
UI event handling code typically runs in iothread context. So, yes,
when calling qemu_input_* the UI code holds the iothread lock.
> (To fix a problem on OSX Mojave this patchset has moved
> which thread the UI executes on, so it is now always
> the main thread and not the thread which calls
> the QemuDisplay 'init' callback. That seems to break
> an implicit assumption in the UI layer.)
Hmm, I guess the options are (a) grab the iothread lock before calling
input layer functions, or (b) queue the event and schedule a bottom half
which processes the queue (which will then be called from iothread
context, with the lock already taken).
cheers,
Gerd