On Fri, Jun 13, 2003 at 09:25:49AM -0400, Bruce Momjian wrote:
>
> malloc() - should fail right away if it can't reserve the requested
> memory; assuming application request memory they don't use just seems
> dumb --- fix the bad apps.
>
> fork() - this is the tricky one because you don't know at fork time who
> is going to be sharing the data pages as read-only or doing an exec to
> overlay a new process, and who is going to be modifying them and need a
> private copy.
>
> I think only the fork case is tricky.
But how do you tell that a malloc() can't get enough memory, once you've
had to overcommit on fork()s? If a really large program did a regular
fork()/exec() and there wasn't enough free virtual memory to support
the full fork() "just in case the program isn't going to exec()," then
*any* malloc() occurring between the two calls would have to fail. That
may be better than random killing in theory, but the practical effect
would be close to that.
There's other complications as well, I'm sure. If this were easy, we
probably wouldn't be discussing this problem now.
Jeroen
