Re: Failure to allocate gtk object

[John Cupitt <jcupitt gmail com>]

On 10/6/05, Nikolaj Kiær Thygesen <Nikolaj Thygesen ciber dk> wrote:
>         ... and after a number of years developing phones for the low-end market I'm very much used to the 
> low-resource situation :o) I feel a slight discomfort from not checking pointer return values, but if it's 
> to no avail then...

Heh, yes, I used to write videogames, so it's a bit similar. From
habit I always check returns in my own libraries and it feels odd to
me too. Perhaps another answer is that GTK is designed as a desktop
GUI toolkit and is not so suitable for high reliablility or low
resource environments.

>         It would just be annoying to have done large amounts of work in a program just to have it crash all 
> the sudden because it couldn't allocate a widget.
>         Since you suggested that I should "provide your own memory alloc", does that mean that I can force 
> gtk allocation of widgets to use my own custom memory allocation schemes???

Yes, see:

http://developer.gnome.org/doc/API/2.0/glib/glib-Memory-Allocation.html#g-mem-set-vtable

You can provide your own malloc() implementation that does something like:

gpointer
my_malloc( gsize n )
{
  void *p;

  if( !(p = malloc( n )) ) {
    // or whatever ... do something that you know will free a lot
    // of RAM and is safe to call, even during a _new(), and
    // which is guaranteed not to call malloc() itself.
    // you could even malloc() a megabyte or so as your program
    // starts as a "guard area" and not use it, then free() when you
    // get the first out-of-mem and warn the user
    my_cache_flush();

    if( !(p = malloc( n )) ) {
      // we are totally screwed
      exit( ENOMEM );
    }

    // set a flag ... our main loop tests this regularly
    // and warns the user somehow
    my_low_mem_warning = TRUE;
  }

  return( p );
}

> I'm pretty unexperienced with gtk, so I might be asking stupid questions here, but did anyone ever suggest 
> implementing exception-like error-handling in gtk...??? you know like the setjmp()/longjmp() variation 
> found in some packages.

Yes, this has been proposed a few times, but I think no one really
liked the idea when it came to the details. It would make gtk a lot
more complicated for a rather marginal improvement for most use cases.

John