SV: Failure to allocate gtk object

[Nikolaj Kiær Thygesen <Nikolaj Thygesen ciber dk>]

        ... 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...
        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??? 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.
        Maybe I'm just a bit old-fashioned.

        br - N :o)

-----Oprindelig meddelelse-----
Fra: John Cupitt [mailto:jcupitt gmail com]
Sendt: 6. oktober 2005 00:25
Til: Nikolaj Kiær Thygesen
Cc: gtk-app-devel-list gnome org
Emne: Re: Failure to allocate gtk object


On 10/5/05, Nikolaj Kiær Thygesen <Nikolaj Thygesen ciber dk> wrote:
>     Just a quickie... What happens if the gtk_*_new() function fails to allocate memory for a widget??? 
> From looking at sources I'm under the impression that the program will simply exit, but, if so, is there 
> any way of keeping it afloat and reveive a NULL-pointer-return instead???

Nope, the _new() funcs are not allowed to return NULL. You can do two things:

1) provide your own memory alloc, catch out-of-mem, free some stuff
(perhaps flush a cache?) and retry
2) if you allocate memory yourself (perhaps for a large cache?), you
can use g_try_malloc() instead, which can return NULL

I think the argument is that it is very difficult to recover
gracefully from out-of-mem in a GUI, since almost any action you might
take to recover will itself require some memory to be allocated.

In any case, out-of-mem is very rare for most programs, thanks to
virtual memory and friends. Programs which are allocating enough stuff
to possibly fill memory are probably so 'heavy' that the resource
intensive work could be split off to another process to avoid crashing
into the GUI code. I guess things are different for people working
with embedded systems.

John