> 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. 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. > Ideally SDL should provide an API to get a pollable fd (or a set of) to allow > such types of integration, not much can be done from QEMU side in its current > form. I'm glad you reached more or less the same conclusion as I mentioned in one of the previous messages: > I guess making SDL run asynchronously will need some major changes to the SDL > source code, not simple patches that can be added to the QEMU build. regards, Liviu
