Re: Emergency memory pool for Glib


By default in embedded development we usually block on OOM.  But we
have also done the interface such that an application can make a
non-blocking call if desired.  It's then up to the application to
decide what to do if the requested memory is not available.

Like I said, it's much more common in our code to request that our
equivalent mem_allocate() block if memory is not available .  In this
situation, if memory runs out, these threads will hang.

Our memory manager provides statistics that can be used by a monitor
thread to detect the out of memory condition.  If detected, the
monitor thread could log a message and reboot the application or

So we rely on a lot of testing and debugging based on these conditions
and log files.  I am not sure if that information helps, but it is
atleast what I have done in the past with embedded development.


On 7/13/06, Federico Mena Quintero <federico ximian com> wrote:

One important thing, especially for embedded devices, is to ensure that
GTK+ apps won't abort() when g_malloc() fails.

I've started a wiki page to discuss having an emergency memory pool:

[Robert O'Callahan says that Nokia has a patch to do something like
this... can we simply use it?]



gtk-devel-list mailing list
gtk-devel-list gnome org

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