glib dependency for the X Server

[Carsten Haitzler (The Rasterman)]

On Mon, 3 Apr 2006 14:00:02 -0400 "Ray Strode" <halfline at gmail.com> babbled:

> Hi,
> 
> On 4/3/06, Erwin Rol <mailinglists at erwinrol.com> 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).
> glib already has a mechanism for making memory allocation calls not
> abort. You can just do g_mem_set_vtable and pass g_try_malloc as the
> malloc handler.  Then g_malloc will return NULL on OOM.  The problem
> is none of the glib data structures expect g_malloc to return NULL so
> instead of abort you'll just hit a segfault from NULL pointer
> dereferencing and such.
> 
> I don't think it would be too hard to change most of glib's data
> structures to handle NULL malloc returns gracefully, but I could be
> wrong.  You'd have to be careful about some things like statically
> allocating a special OOM GError for functions that return GErrors, and
> in some case it might be hard to keep function semantics exactly the
> same in the default abort() case.  It would also add a lot of error
> checking code that will never be hit in apps (becuase by default glib
> would still abort()). On linux with the default over committing
> behavior enabled the error checking code is pretty worthless too,
> because the kernel will just kill programs randomly on Out of memory
> instead of return NULL from a malloc.

the difference is that you should at least TRY to do the right thing.
overcommitting is optional and can be turned off in the kernel trivially. (echo
2 > /proc/sys/vm/overcommit_memory).

the problem is - if you run out of memory, you xterm crashing is bad, x
crashing is effectively almost as bad as a system crash - you lose ALL your
apps. the xserver should do it's best to do things right - rewind alloc errors
and fail gracefully. if an app can't create a window due to being out of memory
- then so be it. a window doesn't come up. it's far better than losing your
whole desktop.

so glib needs to NOT assume allocs succeed and provide a sane way to return
such errors. g_list_append() for example needs semantics as to how to indicate
its alloc failed (if it returns NULL you will lose your list unless you use a
tmp list pointer and check/set it back later which makes glib more unweildy to
use - or you can use an errno style get_error() thing where the error flag is
set if the alloc failed and the return is simply a safe value (the previous list
pointer base) etc.)

> If X doesn't currently handle OOM gracefully anyway, then it seems
> like a silly requirement though.
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster at rasterman.com
裸好多
Tokyo, Japan (東京 日本)