glib dependency for the X Server

[Owen Taylor]

On Mon, 2006-04-03 at 12:58 +0200, Erwin Rol wrote:
> On Mon, 2006-04-03 at 19:41 +0900, Carsten Haitzler wrote:
> 
> > > So I think glib wouldn't be that bad of a choice. 
> > 
> > abort().
> 
> Did anybody asked the glib developers if that could be changed ? It
> would probably not be that big a deal to add some OOM handler that
> defaults to abort() but can be set to something else by the user (Xorg
> in this case). 

The problem is that you can't just handle out-of-memory in *one* place,
you have to propagate the ability to fail throughout the whole API.

While I have considerable doubts that the X server survives memory
allocation failures in all places... at least in theory the code
checks all returns, keeps the internal state consistent, and propagates
errors back up to higher layers. 

This is something we long ago decided against for the GLib and the
GTK+ stack. We didn't want application developers to have to worry about
what to do if g_list_append(), g_timeout_add(), gtk_entry_set_text(),
gtk_widget_show(), and thousands and thousands of other calls ran out
of memory.

So making malloc optionally not abort isn't really an option since it
would imply changing the signature of almost every function in everal
library depending on GLib and also changing almost every line of
code :-). 

					Owen

The basic GLib malloc actually *doesn't* abort ... g_malloc() is a
wrapper around g_try_malloc() which we use directly in places like
gdk_pixbuf_new_from_file() where external factors might cause huge
amounts of memory to be allocated.