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 <aligu...@us.ibm.com> > 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
