On Mon, 12/12 17:07, Liviu Ionescu wrote: > > > On 12 Dec 2016, at 16:51, Fam Zheng <f...@redhat.com> wrote: > > > > On Mon, 12/12 15:22, Liviu Ionescu wrote: > >> so, back to square one; any suggestion on how to avoid the periodic timer > >> required to poll SDL system events? > > > > Good question, I've missed that! > > > > Sadly I don't find it possible. The main thread of QEMU has to run the glib > > event loop so it cannot block on SDL_WaitEvent(). > > why should the glib event loop run as the main thread? according to my tests, > on linux and macos the glib event loop can run very well on a regular thread.
According to the API documentation I think it is supposed to work, but it will be an unusual use case anyway so it's presumably less tested and I remember hearing about things break here and there (cannot recall any detail :(). > > the problem that I encountered with this approach was on windows, where there > is no `poll()`, and the existing implementation of it in qemu does not work if > moved on a different thread. I do not know if the qemu implementation is not > correct, or the win32 api does not allow this. > > > ... it cannot block on SDL_WaitEvent(). > > initially I considered that rearranging threads to free the main thread for a > dedicated SDL loop that blocks on SDL_WaitEvent() is a good solution, but then > I took a look at how SDL_WaitEvent() is implemented: a loop that sleeps 10 ms > and checks if there are events in the queue. :-( > > so the best solution would be to make SDL asynchronous and run it on the glib > event loop. Maybe, but that would be a big project. Given how SDL_WaitEvent() works as you said above, the easies solution would be using qemu_bh_schedule_idle in the QEMU main loop and poll event there periodically. Fam
