ASU - out of memory?

Chris Wright dhasenan at gmail.com
Fri Aug 22 18:36:52 CEST 2008


2008/8/22 Chris Wright <dhasenan at gmail.com>:
> 2008/8/22 Tilman Baumann <tilman at baumann.name>:
>> Pardon.
>> I don't care for the warm and fuzzy feeling you get by having malloc
>> fail on you.
>>
>> It does not give you a bit more system stability! The one app
>> receiving malloc errors is just not app of many. They all have a
>> problem then.
>> Imagine, the browser catches a failed malloc, because some other
>> stupid app has eaten almost all ram.
>> What is the benefit of telling the browser about low mem? It could
>> only safe itself from crashing. Well done.
>
> Imagine that malloc() returns null rather than overcommitting.
> Most affected apps will receive a SIGSEGV when malloc returns null
> because there's no error handling for that situation.
> Some will notice that malloc() returned null and either forgo some
> optional stuff or abort a single operation or simply just shut down
> gracefully.

On the other hand, let's say your process allocates some memory and
doesn't use it for a while. In the meantime, some memory is freed.
This doesn't help if malloc() returned null, but it does help if the
kernel overcommitted memory instead.

I don't think that's as useful. But you could instead define a malloc:
void* _malloc(size_t length)
{
   void* pointer = malloc(length);
   if (!mlock(pointer, length)) return null; // or abort
   return pointer;
}




More information about the community mailing list