Re: Setting memory allocators for library functions.

[Dag-Erling Smorgrav]

[EMAIL PROTECTED] (Peter Seebach) writes:
> In message <[EMAIL PROTECTED]>, Dag-Erling Smorgrav writes:
> >Malloc() does not overcommit - the kernel does. Malloc() doesn't know
> >and doesn't care.
> But it could still probably force the behavior.

Barring kernel changes, not easily, and only for single-threaded
programs.

> > None of these solutions are portable, however;
> Well, no, but the sole available definition of "portable" says that it is
> "portable" to assume that all the memory malloc can return is really
> available.

Show me a modern OS (excluding real-time and/or embedded OSes) that
makes this guarantee.

> > memory overcommit is to write a malloc() wrapper that installs a
> > SIGSEGV handler, then tries to dirty the newly allocated memory, and
> > fails gracefully if this causes a segfault.
> Ugh.  Why not just have a flag for memory requests that requires the memory
> not to be overcommitted, and set it in "conforming mode"?

Read the paragraph that precedes the one you're quoting.

DES
-- 
Dag-Erling Smorgrav - [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message