On 01/24/2011 03:28 PM, Paolo Bonzini wrote:
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).
Not sure how much either of these matter, but we should at least drop
QObject and convert our JSON parser to use GValues such that we can
treat the JSON parser as a stand alone component.
- 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've been thinking about this myself. I think slirp is probably best
handled as a GSource as much as I don't want to do it. I don't see
another option.
We can't use the g_timeout_source directly because the interval is
milliseconds. Since our clock mechanisms all use signals to generate
clock events, I think we can tie it all to a pipe() and just use a
GIOChannel to generate events. Obviously, implementing a GSource is the
best long term approach but I think there's a reasonable short term one.
Regards,
Anthony Liguori
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
