From owner-freebsd-hackers Sat Feb 24 15: 3:25 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from guild.plethora.net (guild.plethora.net [205.166.146.8]) by hub.freebsd.org (Postfix) with ESMTP id 1792637B491 for ; Sat, 24 Feb 2001 15:03:20 -0800 (PST) (envelope-from seebs@guild.plethora.net) Received: from guild.plethora.net (seebs@localhost.plethora.net [127.0.0.1]) by guild.plethora.net (8.10.1/8.10.1) with ESMTP id f1ON3E620236 for ; Sat, 24 Feb 2001 17:03:16 -0600 (CST) Message-Id: <200102242303.f1ON3E620236@guild.plethora.net> From: seebs@plethora.net (Peter Seebach) Reply-To: seebs@plethora.net (Peter Seebach) To: freebsd-hackers@freebsd.org Subject: Re: Setting memory allocators for library functions. In-reply-to: Your message of "24 Feb 2001 23:14:27 +0100." Date: Sat, 24 Feb 2001 17:03:12 -0600 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message , Dag-Erling Smorgrav writes: >It doesn't (and I'm very close to using expletives here). On the >contrary, it tries to always satisfy the application's requests and >hopes for the best. Yes, but it could provide a stronger guarantee than it does. >It's quite possible that memory isn't available >when you call malloc(), but becomes available before you actually get >to dirty the pages that were allocated. Sure. And for many applications, that's a win. For some, though, the *CHANCE* of overcommitting killing the process is a serious problem, and the application would be better off if it could warn the user that insufficient memory is available, and perhaps more should be provided. It would be a useful option. I'm not saying it's the *only* useful option, or even always the best. However, it should be trivial enough to provide this option, and it *does* serve a useful purpose. -s To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message