Re: glib CVS ?

[Johannes Stezenbach <js convergence de>]

On Mon, Nov 26, 2001 at 12:34:07PM +0100, Tim Janik wrote:
> On Mon, 26 Nov 2001, DINH V. Hoa wrote:
> 
> > I really think that a library should not make a decision for
> > the program that uses it do fail and to exit.
> 
> if we didn't do this, we'd have to pass up malloc errors through
> virtually every public function, quite impossible if you think of
> the usual call stack depth of the average gtk program.

Call stack depth is no valid argument against error checking.
It's certainly easier to add proper out-of-memory (OOM) handling
when the implementation language supports exception handling,
but it's not impossible to do it in C.
I think ignoring OOM errors was a policy decision to make the API
more convenient for typical desktop applications, where real OOM situations
are rare. Given that Gtk+ was first a part of Gimp, that decision
was OK.

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

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


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

Regards,
Johannes