Re: [Qemu-devel] [PATCH] Fix for crashes and non-responsive UI on macOS Mojave

[Gerd Hoffmann]

  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