On Wed, Jan 26, 2011 at 3:53 PM, Anthony Liguori <aligu...@linux.vnet.ibm.com> wrote: > On 01/25/2011 10:47 PM, Daniel Veillard wrote: >> >> On Mon, Jan 24, 2011 at 03:00:38PM -0600, 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. >>> >> >> Hum, one of the reason I tried to avoid glib dependancies on my own >> libraries code is the behaviour on memory allocation error, unless that >> changed (unlikely) or my recollection is wrong (more likely) glib does >> a direct exit() on memory allocation errors. This might be fine for QEmu >> as a standalone program but may turn a disaster if standalone libraries >> are made out of it and expected for reuse say by libvirt(d). >> > > We have independently done the same thing in QEMU and as such would face the > same "problem" either way. > > Quite a debate could be had on the merits of this. For QEMU, we made this > decision for practical purposes. We did not handle malloc failures > consistently so adopting a consistent behavior eliminated the possibility of > NULL pointer dereferences which are exploitable.
Both g_malloc() and g_try_malloc() are available where g_try_malloc() returns NULL on failure. g_malloc() matches qemu_malloc() exit behavior today but in the future it would be possible to use g_try_malloc() for proper out-of-memory handling. But I think you're pointing out that glib uses g_malloc() internally. That is a design flaw and basically makes g_try_malloc() useless. Stefan
