Date: Wed, 14 Apr 1999 17:19:47 -0700 From: "David Schwartz" <davids@webmaster.com> To: "Chuck Robey" <chuckr@picnic.mat.net>, "Anthony Kimball" <alk@pobox.com> Cc: <chat@FreeBSD.ORG> Subject: RE: swap-related problems Message-ID: <000101be86d5$ab65bcc0$021d85d1@whenever.youwant.to> In-Reply-To: <Pine.BSF.4.10.9904141841070.18456-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> But, as long as you keep resources resonable, that's precisely what you > get under memory overcommit. If you'd see a failure under memory > overcommit, you'd have seen the failure far sooner without memory > overcommit. The only other difference is which signal kills your > program. With memory overcommit, the chances of that program running > without errors, in full ANSI C compliance, are far, far higher. There is a very significant difference between failures a programmer can plan for and expect, such as malloc or fork returning a sensible error code, and failures a programmer cannot plan for or expect, such as receiving a fatal signal when performing a simple assignment operation. If a programmer doesn't correctly handle the case where malloc returns NULL, that's his fault. If the system returns him a pointer to memory and he faults when he tries to access it, that's not. It should, ideally, be at least possible to write programs that run reliably. That doesn't mean that some people won't want to be able to overcommit. DS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000101be86d5$ab65bcc0$021d85d1>