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

[Johannes Stezenbach]

Hi,

just a few thoughts from a qemu novice...

On Mon, Jan 24, 2011 at 03:00:38PM -0600, Anthony Liguori wrote:
> 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.

My personal experience with the GMainLoop is that it adds
a lot of processing overhead compared to hand-written code.
However, this is from a few years back and was on an embedded
system, and I don't have numbers to back up my claim...
Looking at the GMainLoop code I'd say it's not written
for high performance, but on the plus side it handles cases
like recursive invocation and adding/removing event sources
to another thread's GMainLoop.

Anyway, in case you expect high performance you might
want to benchmark it against something like libevent.

> 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.

I found working with GObjects by writing C code manually
extremely error prone and boring.  However, I hear Vala
is the new way if you're determined to use GObject:
http://live.gnome.org/Vala
(Note that I haven't used Vala myself, and this is not a recommendation
for Vala; what I want to say is: if Vala doesn't work for you
you'll have a lot of fun with GObject.)

Regarding dynamic language bindings:  One side effect of that is that
all arguments and return values from g_signal_emit() signal handlers
are marshaled via an elaborate scheme just in case there might be
a script language binding in the mix.  Again, this is clearly not
written for high performance.  I'm not sure this is relevant for
qemu, but you might want to take a look at Glib sources and do some
benchmarks before using to avoid unpleasant surprises.


Johannes