Re: phk malloc, was (Re: ptmalloc2)

[Gary Thorpe <gathorpe79@xxxxxxxxx>]

David Xu wrote:

> Dan Melomedman wrote:
>
> > Bill Hacker wrote:
> >
> > > If the 'email proxy in question' is that fragile - your statement 
> > > would appear to be true.
> >
> >
> >
> > It's only fragile because the OS doesn't guarantee preallocated memory.
> > That's all. Anyway, I've made the decision to only run software like
> > this on Linux. Linux actually has the system-wide overcommit switch 
> > through
> > 'sysctl'. I wish I could switch it on and off per process through an
> > environment variable instead. Oh well, can't have it all.

BSD/UNIX does not guarantee it's loans. Preallocating resources is 
supposed to guarantee or at least improve reliability, but in this case 
it doesn't.

> You will have an unusable machine if you turn on overcommit,
> when memory is about to be exhausted, any code not written by you
> will crash because they don't check if malloc will fail!
> Any program and system utilities will core dump or be locked there
> if memory is exhausted, in the machine, your code only occupies
> 1/10000 or less, making 1/10000 code to be overcommit aware does not
> make sense.
>
> Regards,
> David Xu

Look: the point about reliability is that user-land software CANNOT 
detect overcommit. They do a call to malloc() and it returns NON-NULL. 
Later, they try to use the memory they allocated and get killed (along 
with any other unfortunate processes that happen to cause page faults) 
when the system runs out of memory. How do you write reliable programs 
in this case?