[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib
From: |
Edgar E. Iglesias |
Subject: |
Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib |
Date: |
Tue, 25 Jan 2011 07:51:25 +0100 |
User-agent: |
Mutt/1.5.20 (2009-06-14) |
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 <address@hidden>
> 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
- Re: [Qemu-devel] Re: [PATCH 4/7] Get rid of QemuMutex and teach its callers about GStaticMutex, (continued)
[Qemu-devel] [PATCH 1/7] io-thread: make sure to initialize qemu_work_cond and qemu_cpu_cond, Anthony Liguori, 2011/01/24
[Qemu-devel] [PATCH 5/7] threads: get rid of QemuCond and teach callers about GCond, Anthony Liguori, 2011/01/24
[Qemu-devel] Re: [RFC 0/7] Introduce hard dependency on glib, Paolo Bonzini, 2011/01/24
Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib, Anthony Liguori, 2011/01/24
- Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib,
Edgar E. Iglesias <=
Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib, Stefan Hajnoczi, 2011/01/25
Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib, Gerd Hoffmann, 2011/01/25
Re: [Qemu-devel] [RFC 0/7] Introduce hard dependency on glib, Aurelien Jarno, 2011/01/25
Message not available