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).