From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38544) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaL6Q-0008PO-0S for qemu-devel@nongnu.org; Fri, 11 Sep 2015 05:58:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZaL2U-00057n-0z for qemu-devel@nongnu.org; Fri, 11 Sep 2015 05:54:42 -0400 References: <1438144934-23619-12-git-send-email-famz@redhat.com> <55B882C1.8070500@redhat.com> <20150729105725.GA10376@ad.nay.redhat.com> <55B8B2C3.9050307@redhat.com> <20150729115333.GA15022@ad.nay.redhat.com> <55B8C12D.2070105@redhat.com> <20150909032205.GA10922@ad.nay.redhat.com> <55F28D99.5060908@redhat.com> <20150911091433.GA6759@ad.nay.redhat.com> <20150911094425.GA9241@ad.nay.redhat.com> From: Paolo Bonzini Message-ID: <55F2A4D6.6050009@redhat.com> Date: Fri, 11 Sep 2015 11:54:30 +0200 MIME-Version: 1.0 In-Reply-To: <20150911094425.GA9241@ad.nay.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [Qemu-block] [PATCH v2 11/11] block: Only poll block layer fds in bdrv_aio_poll List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Fam Zheng , Alberto Garcia Cc: kwolf@redhat.com, stefanha@redhat.com, qemu-devel@nongnu.org, qemu-block@nongnu.org On 11/09/2015 11:44, Fam Zheng wrote: > > > > That would be a step back. Using GSource is useful because it le= ts > > > > you integrate libraries such as GTK+. > > > > > > Can we move GTK to a separate GSource thread? > >=20 > > I think that GTK should always run in the main thread, or at least th= e > > one running the default main loop / GMainContext. >=20 > Yeah it's basically GMainContext staying in the main thread and > block/net/chardev I/O put in a new AioContext thread. Why? The point of an event loop is that you can multiplex everything on the same thread. Unless we have specific needs (e.g. scalability) one thread is the way to go and keep things simple. The tool we have for scalability is AioContext + dataplane threads, and because we _can_ integrate it into the main thread (AioContext is a GSource) we can write code once for the main thread and for external dataplane threads. Using AioContext instead of duplicating the code is great. Moving SLIRP to Win32 would get rid of all the duplicated select() code between aio-win32.c and main-loop.c. A lot of main-loop.c code can go away (probably not all because unlike glib we support nanosecond timeouts with TimerListGroup, but who knows). However, there is no need to deviate the event loop from the well-known, standardized glib architecture. Paolo