From owner-freebsd-current@FreeBSD.ORG Mon Jan 7 23:20:25 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 4983016A41A for ; Mon, 7 Jan 2008 23:20:25 +0000 (UTC) (envelope-from andrew-freebsd@areilly.bpc-users.org) Received: from omta02ps.mx.bigpond.com (omta02ps.mx.bigpond.com [144.140.83.154]) by mx1.freebsd.org (Postfix) with ESMTP id BFA4D13C478 for ; Mon, 7 Jan 2008 23:20:24 +0000 (UTC) (envelope-from andrew-freebsd@areilly.bpc-users.org) Received: from oaamta06ps.mx.bigpond.com ([124.188.162.219]) by omta02ps.mx.bigpond.com with ESMTP id <20080107232023.WIO28980.omta02ps.mx.bigpond.com@oaamta06ps.mx.bigpond.com> for ; Mon, 7 Jan 2008 23:20:23 +0000 Received: from areilly.bpa.nu ([124.188.162.219]) by oaamta06ps.mx.bigpond.com with ESMTP id <20080107232023.SNKU29535.oaamta06ps.mx.bigpond.com@areilly.bpa.nu> for ; Mon, 7 Jan 2008 23:20:23 +0000 Received: (qmail 3644 invoked from network); 7 Jan 2008 23:19:42 -0000 Received: from localhost (HELO duncan.reilly.home) (127.0.0.1) by localhost with SMTP; 7 Jan 2008 23:19:42 -0000 Date: Tue, 8 Jan 2008 10:19:42 +1100 From: Andrew Reilly To: "Poul-Henning Kamp" Message-ID: <20080108101942.05471233@duncan.reilly.home> In-Reply-To: <10319.1199711927@critter.freebsd.dk> References: <10319.1199711927@critter.freebsd.dk> X-Mailer: Claws Mail 3.0.2 (GTK+ 2.12.3; amd64-portbld-freebsd7.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Cc: Kostik Belousov , Peter Jeremy , freebsd-current@freebsd.org, 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: Mon, 07 Jan 2008 23:20:25 -0000 On Mon, 07 Jan 2008 13:18:47 +0000 "Poul-Henning Kamp" wrote: > Yes, but you will not see this complication, it will be hidden > in the implementation of malloc(3). How could you hide it inside malloc? Would malloc start returning 0 after receiving the "less mem than desirable" signal? Would it ever go back to returning non-zero? I thought that the idea of things like SIGDANGER was that applications would be written to have a mode where they could shut down some aspect of their operation, and free resources. I don't see how you can do that, autonomously, from within malloc? Maybe introduce a special flavour of pointer value, returned by a special version of malloc for "cache" objects, that the system is allowed to automatically reclaim? Then programs would need to be able to handle SIGSEGV when accessing those... Cheers, -- Andrew