On Wed, 2004-12-29 at 10:46 +0100, Baurjan Ismagulov wrote: > Hello Tristan, > > On Tue, Dec 28, 2004 at 02:21:49PM -0500, Tristan Van Berkom wrote: > > but seriously, I think it would be a noble cause to make `abort()' on oom > > optional but it would require alot of work. The entire GTK+ codebase would > > have to be refactored. To start with: class / instance initialization > > functions in > > GObject would have to support oom conditions and return FALSE if they werent > > capable to allocate enough resources (right now they return `void'). > > > > many many lines of code... But IMO, definitly a noble cause :) > > I've thought about this, but I don't have that much time right now -- it > would imply redefinition of interfaces. What I was asking about was just > to define something like g_set_oom_handler and call it instead of > abort(). So, my question remains: would it be enough to modify g_error? g_mem_set_vtable() allows you to replace the guts of g_malloc. Then you can determine what happens when malloc() returns NULL before GLib calls g_error(). If you can find sufficient memory by freeing caches or whatever and actually allocate the requested memory, then you can avoid aborting. Note that in your malloc handler you can't call any GTK+/GDK/Pango/etc. functions. Regards, Owen
Attachment:
signature.asc
Description: This is a digitally signed message part