phk malloc, was (Re: ptmalloc2)

Gary Thorpe gathorpe79 at yahoo.com
Thu Feb 24 20:42:40 PST 2005


Christopher Weimann wrote:
On 02/22/2005-11:33PM, Dan Melomedman wrote:

Another example could be 'dnscache'. It also preallocates the cache
database of user-configurable size at the start-up. It never writes
anywthing to the disk, and it doesn't need to, but I wouldn't want it
to crash because the OS won't have the physical memory it needs on
random basis.


One of the good things about dnscache is that it only allocates what you
tell it to rather than growing forever like BIND. I think the key here
is don't tell it to allocate more than you have and you won't ever have
a problem.
You are misunderstanding the problem: malloc() returns non-NULL even 
though the system cannot actually provide the memory. Applications 
written to expect the possibility that malloc() can fail (good 
programming practice) can still fail due to out-of-memory killing due to 
overcommmit, even though they receive no indication that anything was 
wrong (except the kill signal).



Let's stop here then. The feature I am looking for doesn't come with
Unix by default, beaten horse, etc.


In the case of dnscache at least I don't think it is a feature you need.

Most UNIX systems will allow malloc() to return success even though the 
memory is not available (that's what overcommit is).






More information about the Kernel mailing list