Re: phk malloc, was (Re: ptmalloc2)

[Gary Thorpe <gathorpe79@xxxxxxxxx>]

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