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
