Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib

["Edgar E. Iglesias" <edgar.iglesias@gmail.com>]

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 <aliguori@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