Re: [gtk-list] Re: g_malloc() aborts when enough memory is notfound?
- From: "Emmanuel DELOGET" <logout free fr>
- To: <gtk-list redhat com>
- Subject: Re: [gtk-list] Re: g_malloc() aborts when enough memory is notfound?
- Date: Wed, 3 Nov 1999 12:43:28 +0100
> On Tue, 2 Nov 1999, Emmanuel DELOGET wrote:
> > Hi Owen,
> > I don't know if this is a good idea. If it is possible
> > to extend the callback architecture to glib (for version
> > 1.30, perhaps :)), the abort behavior should be avoided in
> > some cases. Consider the following (in a multiple window
> > text processor)
> g_malloc() is used in a *lot* of places (usually *everywhere* in gtk/gnome
> programs where dynamic allocations are required). most (i.e. 99.999%) of
> these places do *not* check for NULL because g_malloc() is documented
> to never return NULL.
> so a global flag is probably *not* appropriate here.
When I was studying 3 years ago, we developped an allocator library
with multiple global allocation schemes : abort-on-no-mem,
stand-by-on-no-mem, and so on, with a simple allocator object which
could look like this:
void (*g_free_func)(gpointer pointer);
/* additional fields should helps for other tasks */
With this scheme, you can create virtually any type of allocator (debug,
Then you'll need some misc functions such as :
gpointer gallocator_alloc(GAllocator *, size_t);
void gallocator_free(GAllocator *, gpointer);
You can create a glib_normal_alloc that suits the current glib behavior,
redefine g_malloc() to be
#define g_malloc(s) gallocator_alloc(glib_normal_alloc, (s))
#define g_free(p) gallocator_free(glib_normal_alloc, (p))
So you do not need to modify any current gtk/gnome based component, and
you can safely implement a new allocator.
> out of curiosity, how do you popup a dialog if there's no memory
The dialog is created during the init. You also create the label you
(so there is no need for a malloc when you have to show the dialog).
> > Emmanuel
] [Thread Prev