qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] RFC: running the user interface in a thread ...


From: Daniel P. Berrange
Subject: Re: [Qemu-devel] RFC: running the user interface in a thread ...
Date: Tue, 19 Jan 2016 15:37:51 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

On Mon, Jan 18, 2016 at 10:54:40AM +0100, Gerd Hoffmann wrote:
>   Hi folks,
> 
> I'm starting to investigate if and how we can move the user interface
> code into its own thread instead of running it in the iothread and
> therefore avoid blocking the guest in case some UI actions take a little
> longer.
> 
> opengl and toolkits tend to be bad at multithreading.  So my idea is to
> have a single thread dedicated to all the UI + rendering stuff, possibly
> let even the virglrenderer run in ui thread context.
> 
> I think we have to make that opt-in per user interface, so we can go
> forward step by step.
> 
> The ui thread will need quite some stuff provided by the mainloop.  Wait
> for all kinds of events (from vnc socket, x11 connection, ...).
> Probably timers too.  Wait for events from other threads (guest screen
> updates).
> 
> Suggestions how to tackle that?
> Can I reuse the qemu mainloop code outside of the iothread?
> Maybe it'll be better to go straight for a glib main loop?
> Is it possible to wait for file handle events and posix condition
> variables at the same time?
> 
> Other notes / hints / suggestions / ideas?

IIUC, the spice backend already does alot of it work in a background
thread, to avoid stalling the main qemu event loop with potentially
slow tasks.

As a general note though, mixing GTK and threads is really not something
I'd encourage in general. I've battled it with my photo app entangle and
it has been nothing but pain. There are many behavioural differences in
GTK threading with different versions of GTK, so the app frequently broke
with new GTK releases. On Win32 you must *never* call gtk_* functions
from multiple threads, and even on Linux it is deprecated now. The best
pratice is for everything GTK related to be run from a single thread,
ideally the main thread. If any GTK event handler needs to do something
non-trivial it should use  GTask to fire off a background thread todo
the work without blocking the UI.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|



reply via email to

[Prev in Thread] Current Thread [Next in Thread]