From owner-freebsd-current@FreeBSD.ORG Thu Jan 3 22:24:04 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 5C87F16A468 for ; Thu, 3 Jan 2008 22:24:04 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.freebsd.org (Postfix) with ESMTP id ED01A13C465 for ; Thu, 3 Jan 2008 22:24:03 +0000 (UTC) (envelope-from scottl@samsco.org) Received: from phobos.samsco.home (phobos.samsco.home [192.168.254.11]) (authenticated bits=0) by pooker.samsco.org (8.13.8/8.13.8) with ESMTP id m03MNqiu064237; Thu, 3 Jan 2008 15:23:54 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <477D6078.5030805@samsco.org> Date: Thu, 03 Jan 2008 15:23:52 -0700 From: Scott Long User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.11) Gecko/20071128 SeaMonkey/1.1.7 MIME-Version: 1.0 To: =?ISO-8859-1?Q?Dag-Erling_Sm=F8rgrav?= References: <477C82F0.5060809@freebsd.org> <863ateemw2.fsf@ds4.des.no> In-Reply-To: <863ateemw2.fsf@ds4.des.no> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (pooker.samsco.org [168.103.85.57]); Thu, 03 Jan 2008 15:23:54 -0700 (MST) X-Spam-Status: No, score=-1.4 required=5.4 tests=ALL_TRUSTED autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on pooker.samsco.org Cc: freebsd-current@freebsd.org, Jason Evans 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: Thu, 03 Jan 2008 22:24:04 -0000 Dag-Erling Smørgrav wrote: > Jason Evans writes: >> [sbrk is broken] > > The real question is why we would revert perfectly good code (jemalloc) > from using a modern interface to using one that has been obsolete for > twenty years, and marked as such in the man page for seven years. > > If rwatson@ wants malloc() to respect resource limits, he can bloody > well fix mmap(). Until he does, the datasize limit is a joke anyway, as > anyone can circumvent it by either using mmap() instead of malloc() or > setting _malloc_options before calling malloc(). > That is a pretty damning argument in my mind. Why make such a major change right before the release when it's effectively useless? Scott