There is one interesting thing I noticed working on feng and looking at alternative approaches: almost any server software seems to reimplement its runtime. Sometimes, like in the case of Apache, one can accept that it’s because of licensing, some other times I just can’t get why. I know some people say that glib is too heavy and that loading it on a server is a bad idea; I’m not sure how true that is because it also means that every other software is going to need another runtime or a new implementation of almost the same functions each time.
I very well know that glib is far from perfect but I think that’s probably because nobody has been using it for such areas yet, and thus most of these vulnerabilities are client-side (and thus not as much under the spotlight as they could be). But beside that glib also seem to provide lots of client-side interfaces, because of the target it has been designed for (GNOME).
On the other hand, there are quite enough interfaces in glib that allows writing decent server software; while I already expressed my concern about GMime and the fact that it always does lots of little copies of memory areas, glib itself does not suffer from that particular problem. Indeed, glib does not seem to suffer form that problem at all, and provides very customisable interfaces.
There are, of course, a few rough points, for instance Luca is now banging his head on a problem with packet sending that we will probably solve by using a priority queue, but glib does not have one yet (although this bug looks promising ). And as I said, there are more things that needs to be taken care of in the security areas, that I hope to be able to get around to do that in a decent timeframe, and hopefully, not in my spare free time.
All in all, I’d say that glib is pretty decent for server work as well as desktop software.
GLib cannot be used in code where handling malloc() returning NULL is important. malloc() will usually not return NULL on OOM as some uninitiated folks believe, but it *will* return NULL when resource limits are used to limit the adress space used by an application. For most applications and daemons this doesn’t really matter. However, for some core daemons it *does* matter. i.e. glib is a pretty bad choice for an init system, or for the dbus or udev daemon. (i.e. all the same daemons which should fiddle with /proc/$$/oom_adj)GLib has g_try_malloc() as an attempt to make it useful for these cases, too. But that function is a big big joke and should never have been added: all the glib data types do not use it, and neither does GSlice. And hence it doesn’t help at all.