From owner-freebsd-current Wed Apr 14 21:35:14 1999 Delivered-To: freebsd-current@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 7924514D01 for ; Wed, 14 Apr 1999 21:35:06 -0700 (PDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id WAA44290; Wed, 14 Apr 1999 22:32:29 -0600 (MDT) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id WAA07661; Wed, 14 Apr 1999 22:32:26 -0600 (MDT) Message-Id: <199904150432.WAA07661@harmony.village.org> To: mi@aldan.algebra.com Subject: Re: swap-related problems Cc: current@FreeBSD.ORG In-reply-to: Your message of "Wed, 14 Apr 1999 19:40:07 EDT." <199904142340.TAA96857@misha.cisco.com> References: <199904142340.TAA96857@misha.cisco.com> Date: Wed, 14 Apr 1999 22:32:26 -0600 From: Warner Losh Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In message <199904142340.TAA96857@misha.cisco.com> Mikhail Teterin writes: : Then, one can write a safe malloc, which will install the signal : handler, and touch every page in the the memory referenced by the : to-be-returned pointer. If the signal handler is invoked in the : progress, the to-be-returned memory must be returned back to the : system and NULL should be returned to the caller. This won't work all the time. FreeBSD overcommits swap space and you may get a SIGKILL even if you've touched all the pages. FreeBSD kills processes when swap space runs out. : However, my (in)ability to propose anything remotely sensible does : not change the facts established in this painful thread. That our : malloc does not conform to standards (for whatever reasons), and : that something should be done about it. That "something" must start : with documenting the flaw... The behavior is documented: The malloc() and calloc() functions return a pointer to the allocated memory if successful; otherwise a NULL pointer is returned. What the system does when it has resource shortages is beyond the scope of the ANSI-C standard, so I don't see why you say that FreeBSD's malloc isn't standard conforming. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message