Re: Emergency memory pool for Glib

["Sean Kelley" <sean sweng gmail com>]

Hi,

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
system.

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.

Sean

On 7/13/06, Federico Mena Quintero <federico ximian com> wrote:
> Hi,
>
> 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:
>
>         http://live.gnome.org/GTK%2B/LowMemoryPool
>
> [Robert O'Callahan says that Nokia has a patch to do something like
> this... can we simply use it?]
>
> Thoughts?
>
>   Federico
>
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list