From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:51457)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1aL6WL-00080O-1J
	for qemu-devel@nongnu.org; Mon, 18 Jan 2016 04:54:45 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1aL6WJ-0003eJ-MC
	for qemu-devel@nongnu.org; Mon, 18 Jan 2016 04:54:44 -0500
Received: from mx1.redhat.com ([209.132.183.28]:38843)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <kraxel@redhat.com>) id 1aL6WJ-0003eF-Gr
	for qemu-devel@nongnu.org; Mon, 18 Jan 2016 04:54:43 -0500
Received: from int-mx14.intmail.prod.int.phx2.redhat.com
	(int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27])
	by mx1.redhat.com (Postfix) with ESMTPS id 204F72F147C
	for <qemu-devel@nongnu.org>; Mon, 18 Jan 2016 09:54:43 +0000 (UTC)
Message-ID: <1453110880.23289.7.camel@redhat.com>
From: Gerd Hoffmann <kraxel@redhat.com>
Date: Mon, 18 Jan 2016 10:54:40 +0100
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0
Subject: [Qemu-devel] RFC: running the user interface in a thread ...
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel <qemu-devel@nongnu.org>
Cc: David Airlie <airlied@redhat.com>, =?ISO-8859-1?Q?Marc-Andr=E9?= Lureau <mlureau@redhat.com>

  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?

thanks,
  Gerd