From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45517) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMCfp-0007oM-0C for qemu-devel@nongnu.org; Thu, 21 Jan 2016 05:41:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aMCfl-0004pZ-8W for qemu-devel@nongnu.org; Thu, 21 Jan 2016 05:41:04 -0500 Received: from mx1.redhat.com ([209.132.183.28]:49002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aMCfl-0004pT-0k for qemu-devel@nongnu.org; Thu, 21 Jan 2016 05:41:01 -0500 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (Postfix) with ESMTPS id 6753FC796A for ; Thu, 21 Jan 2016 10:41:00 +0000 (UTC) Date: Thu, 21 Jan 2016 10:40:55 +0000 From: "Daniel P. Berrange" Message-ID: <20160121104055.GD19835@redhat.com> References: <1453110880.23289.7.camel@redhat.com> <20160119125109.GA4579@noname.redhat.com> <20160121095811.GA3671@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160121095811.GA3671@stefanha-x1.localdomain> Subject: Re: [Qemu-devel] RFC: running the user interface in a thread ... Reply-To: "Daniel P. Berrange" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Kevin Wolf , David Airlie , =?utf-8?Q?Marc-Andr=C3=A9?= Lureau , Gerd Hoffmann , qemu-devel On Thu, Jan 21, 2016 at 09:58:11AM +0000, Stefan Hajnoczi wrote: > On Tue, Jan 19, 2016 at 01:51:09PM +0100, Kevin Wolf wrote: > > Am 18.01.2016 um 10:54 hat Gerd Hoffmann geschrieben: > > > 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? > > > > That should be possible. The block layer runs additional main loops in > > dataplane threads. I think AioContext is the keyword here, so that you > > process only events in your own UI context. > > > > I'm copying Stefan who knows this stuff a bit better than me. > > > > > Maybe it'll be better to go straight for a glib main loop? > > That sounds good in theory (but see below) since AioContext integrates > with the glib main loop because it is a GSource. QEMU code should use > AioContext where we have high resolution timers and APIs for file > descriptor, EventNotifier, and BH. > > But I think using multiple glib main loops has limitations/problems. > CCing Daniel Berrange because I vaguely remember this topic being > discussed. WRT to GTK you need to be very careful to ensure all gtk_* and gdk_* API calls are made from a single thread. Running multiple glib main loops isn't per-se a problem, as long as you respect that threading requirement. FWIW, spice already has its own background thread that runs its own main loop. > > > Is it possible to wait for file handle events and posix condition > > > variables at the same time? > > I don't think POSIX condition variables can be monitored from an event > loop. Yep, you can't monitor condition vars from poll() > Use BH or EventNotifier instead. BH has optimizations to avoid syscalls > where possible while EventNotifier is just a plain eventfd/pipe > (requires a write() syscall for each notification). 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 :|