From owner-freebsd-chat Thu Apr 15 14:30: 4 1999 Delivered-To: freebsd-chat@freebsd.org Received: from picnic.mat.net (picnic.mat.net [206.246.122.133]) by hub.freebsd.org (Postfix) with ESMTP id 2FB66151AC for ; Thu, 15 Apr 1999 14:29:55 -0700 (PDT) (envelope-from chuckr@picnic.mat.net) Received: from localhost (chuckr@localhost) by picnic.mat.net (8.9.3/8.8.5) with ESMTP id RAA61715; Thu, 15 Apr 1999 17:25:15 -0400 (EDT) Date: Thu, 15 Apr 1999 17:25:15 -0400 (EDT) From: Chuck Robey To: Anthony Kimball Cc: dcs@newsguy.com, chat@FreeBSD.ORG Subject: Re: swap-related problems In-Reply-To: <14102.16644.178732.291963@avalon.east> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 15 Apr 1999, Anthony Kimball wrote: > Quoth Chuck Robey on Thu, 15 April: > > : > I understand this. I concieve the purpose of this thread as being > : > a clear determination of the best known way to allow correctly > : > written code to run reliably when, for reasons perhaps out of the > : > control of the application, memory becomes overcommitted. > : > : It might have been that, if on the second line of your original post you > : didn't claim we were ANSI incompatible. As it was, it sounded much like > : chicken little yelling the sky was falling. Your position now seems to > : have changed quite a bit. > > I'm glad to be corrected where I err. But we are ANSI incompatible No, we are not. Malloc does in fact fail on those conditions. There are additional failures brought on by the OS when some other, possibly unconnected process uses up all your memory, and this is quite thoroughly outside the purview of the ANSI C spec. mi has been told this numerous times, and simply likes to ignore it. The OS simply hunts for the biggest memory hog and kills it. It can't give a signal other than kill, because it' is out of memory, and MUST correct that situation immediately, it can't hunt down the offender (which would be quite difficult) and rely on the offender immediately exiting. It MUST free some memory. This is totally outside the purview of the spec, which we are in compliance with. Sheesh. I'm dropping this thread, if I see one more post from mi where it's obvious he hasn't bothered to read a response, I'll embarrass myself and get mad. What gets me is, the work done to get our memory overcommit working has given us a great, truly great VM situation, and you guys are pretty obviously shooting at it without much understanding. How a hobbyist-built system got so sophisticated amazes me. ----------------------------+----------------------------------------------- Chuck Robey | Interests include any kind of voice or data chuckr@picnic.mat.net | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). ----------------------------+----------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message