From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46323 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PhckY-0006vy-SS for qemu-devel@nongnu.org; Tue, 25 Jan 2011 01:51:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PhckX-00023n-L1 for qemu-devel@nongnu.org; Tue, 25 Jan 2011 01:51:34 -0500 Received: from mail-ey0-f173.google.com ([209.85.215.173]:35521) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PhckX-00023a-Au for qemu-devel@nongnu.org; Tue, 25 Jan 2011 01:51:33 -0500 Received: by eyg7 with SMTP id 7so2525250eyg.4 for ; Mon, 24 Jan 2011 22:51:31 -0800 (PST) Date: Tue, 25 Jan 2011 07:51:25 +0100 From: "Edgar E. Iglesias" Subject: Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib Message-ID: <20110125065125.GA412@laped.lan> References: <1295902845-29807-1-git-send-email-aliguori@us.ibm.com> <4D3E182D.7080308@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4D3E182D.7080308@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Stefan Hajnoczi , Marcelo Tosatti , qemu-devel@nongnu.org, Paul Brook , Arun Bharadwaj , Paulo Bonzini On Mon, Jan 24, 2011 at 06:24:13PM -0600, Anthony Liguori wrote: > On 01/24/2011 03:00 PM, Anthony Liguori wrote: > > Both the recent I/O loop and threadlet series have me concerned that we're > > digging ourselves deeper into the NIH hole. I think it's time we look at > > something radical to let us borrow more code from existing projects instead of > > reinventing everything through trial and error. > > > > This series introduces a hard dependency on glib. The initial use is portable > > threads but I see this as just the beginning. Glib/Gobject offer many nice > > things including: > > > > - portable threads > > - rich data structure support > > - INI parser > > - JSON parser > > - generic type system > > - object oriented infrastructure > > - IO library > > - module system > > - introspection to enable support for dynamic language bindings > > > > I see this series as the first step, followed by converting the I/O loop to > > a GMainLoop instance. Once we're there, we can start making deeper use of > > GObjects including converting QDev to a GObject hierarchy. > > > > I've spent the past few months working on C++ integration for QEMU. I'm more > > convinced than ever that we desperately in need of structured object oriented > > mechanisms to be successful but am pretty strongly convinced that incremental > > additional of C++ is not going to be successful. > > > > On the other hand, while GObjects are uglier and require a lot of template code, > > there's more than enough structure that I think it can guide us into a much > > better object model implementation. > > > > There is some ugliness. GLib does not abstract signals because they're very > > non-portable but QEMU makes extensive use of signaling. I don't think it's > > a major issue but some of the ugliness in this series is due to that fact. > > > > This series is only lightly tested but also mostly mechanical. I'm pretty > > confused by the way tcg_halt_cond and friends works so I'm fairly sure I broke > > that (for non-threaded TCG). > > > > Just to share where this is going, attached patch removes the posix-aio > thread pool and replaces it with a GThreadPool. > > Need to do a lot of functional and performance testing before making a > change like this so I'll keep this in a separate series, but thought it > might be interesting. > > Regards, > > Anthony Liguori > > From 5fdc51b2aac307c0219e1489b80bc18e9a3db0d1 Mon Sep 17 00:00:00 2001 > From: Anthony Liguori > Date: Mon, 24 Jan 2011 18:19:08 -0600 > Subject: [PATCH 8/7] posix-aio: convert to glib based thread pool > > This removes the custom pthread based thread pool in favor of a GThreadPool. > I believe this patch implements all of the necessary functionality but it needs > quite a lot more testing and performance analysis. > > One thing I'm sure will break--we used to deliver a signal on every I/O > completion. This just slows down the I/O path. The reason we did this was > because at the time, I believe Cris depended on that signal to break out of > QEMU because it did I/O without a periodic timer installed. Hi Anthony, I have no memory of any such issues. Anyway, if you've got a tree a can clone, I'll be happy to give it a go and let you know if CRIS works ok. There's also a bootable CRIS linux guest image on the wiki's download page if you wan't to try yourself. Cheers