All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrange" <berrange@redhat.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: "David Airlie" <airlied@redhat.com>,
	"Marc-André Lureau" <mlureau@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] RFC: running the user interface in a thread ...
Date: Tue, 19 Jan 2016 15:37:51 +0000	[thread overview]
Message-ID: <20160119153751.GO26662@redhat.com> (raw)
In-Reply-To: <1453110880.23289.7.camel@redhat.com>

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 :|

  parent reply	other threads:[~2016-01-19 15:38 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-18  9:54 [Qemu-devel] RFC: running the user interface in a thread Gerd Hoffmann
2016-01-18 20:34 ` Eric Blake
2016-01-19 13:01   ` Gerd Hoffmann
2016-01-19 13:38     ` Dr. David Alan Gilbert
2016-01-19 14:14       ` Gerd Hoffmann
2016-01-20 14:33         ` Kevin Wolf
2016-01-19 15:19     ` Markus Armbruster
2016-01-19 15:28     ` Daniel P. Berrange
2016-01-20  5:05       ` Eric Blake
2016-01-20  8:45         ` Gerd Hoffmann
2016-01-19 12:51 ` Kevin Wolf
2016-01-21  9:58   ` Stefan Hajnoczi
2016-01-21 10:39     ` Gerd Hoffmann
2016-01-21 10:52       ` Paolo Bonzini
2016-01-21 10:40     ` Daniel P. Berrange
2016-01-19 15:37 ` Daniel P. Berrange [this message]
2016-01-20  7:13   ` Gerd Hoffmann
2016-01-21  8:44 ` Dave Airlie
2016-01-21  9:05   ` Paolo Bonzini
2016-01-21  9:52     ` Gerd Hoffmann
2016-01-21 10:16       ` Paolo Bonzini
2016-01-22  1:38     ` Dave Airlie
2016-01-22  6:59       ` Gerd Hoffmann
2016-01-22  7:14         ` Dave Airlie
2016-01-21  9:00 ` Fam Zheng
2016-01-21  9:45   ` Gerd Hoffmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160119153751.GO26662@redhat.com \
    --to=berrange@redhat.com \
    --cc=airlied@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=mlureau@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.