Date: 24 Feb 2001 21:43:01 +0100 From: Dag-Erling Smorgrav <des@ofug.org> To: seebs@plethora.net (Peter Seebach) Cc: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. Message-ID: <xzp7l2f7qy2.fsf@flood.ping.uio.no> In-Reply-To: seebs@plethora.net's message of "Sat, 24 Feb 2001 14:37:39 -0600" References: <200102242037.f1OKbd618343@guild.plethora.net>
next in thread | previous in thread | raw e-mail | index | archive | help
seebs@plethora.net (Peter Seebach) writes: > In message <xzpg0h37rlq.fsf@flood.ping.uio.no>, 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 - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzp7l2f7qy2.fsf>