On 01/24/2011 03: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
>   - 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.
>
> 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.
>
> This series is only lightly tested but also mostly mechanical.  I'm pretty
> confused by the way tcg_halt_cond and friends works so I'm fairly sure I broke
> that (for non-threaded TCG).
>    

Just to share where this is going, attached patch removes the posix-aio 
thread pool and replaces it with a GThreadPool.

Need to do a lot of functional and performance testing before making a 
change like this so I'll keep this in a separate series, but thought it 
might be interesting.

Regards,

Anthony Liguori