Re: Emergency memory pool for Glib

[Havoc Pennington <hp redhat com>]

Carl Worth wrote:
> 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
> already).

Inert objects would only seem reasonable if your objects/operations are 
doing things that in some sense "can" be skipped; e.g. if you don't 
repaint a window, I guess that isn't catastrophic. (Though sending a 
mangled print job might be...)

The memory pool thing IMO just doesn't work very well though; it's a 
probabilistic/one-time/race-prone hack pretty much.

dbus goes further than both and "actually handles" OOM, i.e. all its 
functions are "transactional" and their effects roll back on OOM, so you 
can retry the operation if OOM is detected. I would not recommend this 
without 100% test coverage *including simulating failure of each and 
every malloc* - dbus has about 70% coverage, and when I added the 
coverage around 5% or so of mallocs were handled in a broken way, and 
fixing them required a number of API changes. So you will NOT get this 
right without extensive testing, though you might write a lot of code 
you think works and think you got it right and sleep at night, you would 
be mistaken ;-)

As another proof, when I added malloc failure testing to libxml2 (which 
thought it had it right) for the first time, libxml2 blew up left and 
right. I think it might be fixed now.

In both the dbus and libxml2 cases, it was quite possibly a waste since 
apps don't check or handle any of the OOM stuff anyway. Well, 
dbus-daemon is the only app that does, at least.

For almost all apps I think gtk pretty much has this right already. 
Aborting (or perhaps sleep() and retry a few times) is all that makes sense.

Remember there's g_try_malloc that apps can use for allocating large 
objects where failure is likely.

Havoc