From owner-freebsd-hackers Sat Feb 24 14:14:34 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id DBB5D37B491 for ; Sat, 24 Feb 2001 14:14:31 -0800 (PST) (envelope-from des@ofug.org) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id XAA57287; Sat, 24 Feb 2001 23:14:27 +0100 (CET) (envelope-from des@ofug.org) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: seebs@plethora.net (Peter Seebach) Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: Setting memory allocators for library functions. References: <200102242158.f1OLwd619758@guild.plethora.net> From: Dag-Erling Smorgrav Date: 24 Feb 2001 23:14:27 +0100 In-Reply-To: seebs@plethora.net's message of "Sat, 24 Feb 2001 15:58:39 -0600" Message-ID: Lines: 15 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG seebs@plethora.net (Peter Seebach) writes: > In message <9877.983050267@critter>, Poul-Henning Kamp writes: > > And just how will the OS know that a particular memory chip will not > > generate an uncorrectable ECC error ? > It can't, but that's no reason for the OS to *add* reasons for failures. 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. 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. 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