Re: Emergency memory pool for Glib

On Thu, 13 Jul 2006 11:01:50 -0500, Federico Mena Quintero wrote:
> I've started a wiki page to discuss having an emergency memory pool:

I've added some notes there on cairo's out-of-memory handling, (since
the page already raised a question about it).

It might even be worth considering cairo's approach for GTK+. It has
benefits similar to a memory pool, but works by returning special,
"inert" objects in out-of-memory situations.

The upside is that the inert objects are static, so they are always
available, (there's no failure mode analagous to memory pool
exhaustion). This allows for applications to defer the check for
successful allocation even longer, and eliminates the question of how
to properly size the memory pool.

A downside is that these new, inert objects are exposed to the
application and might cause unexpected side effects. (In practice, as
I've been switching various parts of cairo's internals to this scheme,
the worst side effect I've found is that switching to an inert-object
scheme defeats previous checks for NULL return values. In GTK+ that
problem shouldn't exist as nobody is checking for NULL return values

Oh, and since cairo's scheme doesn't provide a memory pool, it
wouldn't then provide the extra memory for allocating objects to be
used for error reporting. One solution for this might be to provide a
memory pool for this purpose alone.

Anyway, maybe that's some food for thought.


Attachment: pgpIQxYHSzPaE.pgp
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]