On 01/24/2011 10: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
- IO library
- rich data structure support
These are where GLib shines.
- INI parser
Not compatible with our config files anyway.
- JSON parser
I think our JSON parser is much better than JsonGlib (which isn't anyway
a part of GLib proper).
- generic type system
- object oriented infrastructure
- module system
- introspection to enable support for dynamic language bindings
See below.
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 am not sure how these other bits will look like and maybe it won't
make sense at all, but it doesn't matter. The bits you posted are
already a step in the right direction IMHO, and the same goes for
converting the I/O loop to GMainLoop if you can pull that :) and using
glib's thread pool.
(Regarding GMainLoop, my main worry is that we'd have to reinvent a lot
of GSources to integrate properly with slirp, with QEMU's multiple
clocks, and so on. And GSources are black magic...).
I'd also add to the benefits a good multi-threaded memory allocator.
A small qualm I have is that glib (and GNOME in general) is one of the
hardest pieces of free software to contribute to in my experience. I
have patches which had multiple acks and are still languishing after a
year or so. Still not an excuse for NIH.
Paolo
