On Mon, Jan 24, 2011 at 03:00:38PM -0600, 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.
Hum, one of the reason I tried to avoid glib dependancies on my own
libraries code is the behaviour on memory allocation error, unless that
changed (unlikely) or my recollection is wrong (more likely) glib does
a direct exit() on memory allocation errors. This might be fine for QEmu
as a standalone program but may turn a disaster if standalone libraries
are made out of it and expected for reuse say by libvirt(d).
I just want to raise that point as it's a rather fundamental decision
of the glib/Gnome stack, which was a fine decision to take in the context
of writing GUI framework, but is really a poor one for implementing low level
or server infrastructure,
Daniel