From owner-freebsd-hackers Sun Jul 11 18:27:13 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from relay.is4b.net (peach.oaktree.net.uk [193.82.129.13]) by hub.freebsd.org (Postfix) with ESMTP id 34B5315005 for ; Sun, 11 Jul 1999 18:27:08 -0700 (PDT) (envelope-from jon@chalk.oaktree.net.uk) Received: from chalk.oaktree.net.uk (chalk.oaktree.net.uk [193.82.129.19]) by relay.is4b.net (Postfix) with ESMTP id B13BF1DC0E; Mon, 12 Jul 1999 02:24:24 +0100 (BST) Received: (from jon@localhost) by chalk.oaktree.net.uk (8.9.3/8.9.3) id CAA22848; Mon, 12 Jul 1999 02:24:24 +0100 (BST) Date: Mon, 12 Jul 1999 02:24:24 +0100 From: Jon Ribbens To: "Daniel C. Sobral" Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) Message-ID: <19990712022424.A1390@oaktree.co.uk> Mail-Followup-To: "Daniel C. Sobral" , freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org References: <5laet8b2l8.fsf@assaris.sics.se> <5lemij265u.fsf@assaris.sics.se> <3788714D.4E666FFA@newsguy.com> <19990712002043.C7067@oaktree.co.uk> <3789373D.9B1811F3@newsguy.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <3789373D.9B1811F3@newsguy.com>; from Daniel C. Sobral on Mon, Jul 12, 1999 at 09:30:53AM +0900 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG "Daniel C. Sobral" wrote: > > > OTOH, though, FreeBSD's malloc() is very unlikely to return an out > > > of memory error. > > > > Why is that? > > Because memory (as in *real* memory, either RAM or swap) is > allocated on-demand. So you can allocate any amount of virtual > memory that the system can possibly provide you, even though you'll > run out of memory much earlier, because other resources are also > consuming it. Yuck. That's a complete abomination. What's the point of it? It's turning an out-of-memory situation from an easily-detected recoverable temporary resource shortage which can be worked-around or waited out, into an unrecoverable fatal error. Do a significant number of programs really request memory which they then proceed not to use? > > What happens if the process hits its resource limits? > > If the system runs out of memory, the biggest process is killed. It > might or might not be the one demanding additional memory. No, if the *process* hits its *administrative* resource limits. i.e. setrlimit(2). Cheers Jon -- \/ Jon Ribbens / jon@oaktree.co.uk To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message