Re: glib CVS ?

[Tim Janik <timj gtk org>]

On Mon, 26 Nov 2001, Johannes Stezenbach wrote:

> > considering that 99% of failing malloc()s are due to passing invalid args
> > (such as: 4 - 5) or the system being brought to a halt anyways, and that,
> > even if we handled g_malloc() failing more gracefully, things would usually
> > still blow up in other libs (e.g. xlib), checking NULL malloc() returns would
> > basically screw our API at little to no practical benefit.
> 
> That's certainly wrong for embedded applications. On a device with
> only 16MB RAM w/o swap, you will most likely always work on the edge of
> being OOM, and thus you *must* handle it gracefully.
> 
> If you look at the library dependencies of gtk/gdk-directfb,
> you will find that most of them handle OOM errors and report them
> in their APIs.

*one* dependancy that doesn't is already enough.

> > since most programs would simply exit upon malloc()==NULL anyways - after
> > all, you can't pop up a dialog or somesuch in a situation like this - doing
> > the exit right away in g_malloc() is good enough for most apps.
> > (and those for which this falls short can still hook up their own memory
> > vtable).
> 
> An embedded application would first try to free some memory, e.g.
> clean caches, disable some unimportant functionality. After all,
> all you can do after exiting the application would be to restart it,
> or else the device would be left unusable. And just intermittently
> restarting the application might not look to good to the user...

you can try to free mem by hooking into the mem vtable.

> Good there's something left to do for Gtk+ 3.0.

there's stuff to do for 3.0, but certainly not making
all our functions return NULL suddenly (the vast majority
of our API that returns newly created things, e.g. g_obejct_new()
are guaranteed to never return NULL).

> 
> Regards,
> Johannes
> 

---
ciaoTJ