Date: Mon, 12 Jul 1999 16:56:23 +0900 From: "Daniel C. Sobral" <dcs@newsguy.com> To: Jon Ribbens <jon@oaktree.co.uk> Cc: freebsd-hackers@FreeBSD.ORG, tech-userlevel@netbsd.org, tech@openbsd.org Subject: Re: Replacement for grep(1) (part 2) Message-ID: <37899FA7.4DC4E088@newsguy.com> References: <Pine.GSO.4.10.9907052110250.13873-100000@uther.wam.umd.edu> <xzp7locthir.fsf@flood.ping.uio.no> <xzp1zektgp2.fsf@flood.ping.uio.no> <5laet8b2l8.fsf@assaris.sics.se> <xzpiu7wrx7q.fsf@flood.ping.uio.no> <5lemij265u.fsf@assaris.sics.se> <3788714D.4E666FFA@newsguy.com> <19990712002043.C7067@oaktree.co.uk> <3789373D.9B1811F3@newsguy.com> <19990712022424.A1390@oaktree.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
Jon Ribbens wrote: > > 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? That's *not* abomination. How about pre-allocating over 100 Mb for X Free, for instance? Basically, if you don't have enough memory, you just don't have enough memory. What FreeBSD does *reduces* the need for memory. If FreeBSD *did not* do it, then you'd need much more memory. > > 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). Ah, that's another matter entirely. Then, malloc() returns an error indeed. -- Daniel C. Sobral (8-DCS) dcs@newsguy.com dcs@freebsd.org I'm one of those bad things that happen to good people. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37899FA7.4DC4E088>