... 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:[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]> 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
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
