DragonFly BSD
DragonFly kernel List (threaded) for 2005-02
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: phk malloc, was (Re: ptmalloc2)

From: Gary Thorpe <gathorpe79@xxxxxxxxx>
Date: Thu, 24 Feb 2005 23:42:40 -0500

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

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