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