From owner-freebsd-current@FreeBSD.ORG Fri Jan 4 13:24:29 2008 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8D0B416A420; Fri, 4 Jan 2008 13:24:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 629E213C442; Fri, 4 Jan 2008 13:24:29 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 8E5A14A9FA; Fri, 4 Jan 2008 08:24:28 -0500 (EST) Date: Fri, 4 Jan 2008 13:24:28 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= In-Reply-To: <86abnlag4t.fsf@ds4.des.no> Message-ID: <20080104132310.X77222@fledge.watson.org> References: <86myrlahee.fsf@ds4.des.no> <5647.1199451237@critter.freebsd.dk> <86abnlag4t.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-924143580-1199453068=:77222" Cc: Poul-Henning Kamp , freebsd-current@freebsd.org, Jason Evans , Igor Mozolevsky Subject: Re: sbrk(2) broken X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 04 Jan 2008 13:24:29 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-924143580-1199453068=:77222 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Fri, 4 Jan 2008, Dag-Erling Sm=F8rgrav wrote: > "Igor Mozolevsky" writes: >> This makes memory management in the userland hideously and unnecessarily= =20 >> complicated. It's simpler to have SIGDANGER [...] > > You don't seem to understand what Poul-Henning was trying to point out,= =20 > which is that broadcasting SIGDANGER can make a bad situation much, much= =20 > worse by waking up and paging in every single process in the system,=20 > including processes that are blocked and wouldn't otherwise run for sever= al=20 > minutes, hours or even days (getty, inetd, sshd, mountd, even nfsd / nfsi= od=20 > in some cases can sleep for days at a time waiting for I/O) Another aspect of the problem is that applications have come to depend in= =20 malloc(3) returning NULL when memory is getting tight, and while we have ne= ver=20 done exactly that, we have historically had malloc(3) return NULL when we g= et=20 close to the process data segment size. Robert N M Watson Computer Laboratory University of Cambridge --621616949-924143580-1199453068=:77222--