From owner-freebsd-chat Wed Apr 14 16:10:33 1999 Delivered-To: freebsd-chat@freebsd.org Received: from poboxer.pobox.com (unknown [208.149.16.25]) by hub.freebsd.org (Postfix) with ESMTP id 690B114D0C for ; Wed, 14 Apr 1999 16:10:26 -0700 (PDT) (envelope-from alk@poboxer.pobox.com) Received: (from alk@localhost) by poboxer.pobox.com (8.9.3/8.9.1) id SAA25838; Wed, 14 Apr 1999 18:07:18 -0500 (CDT) (envelope-from alk) From: Anthony Kimball MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Wed, 14 Apr 1999 18:07:17 -0500 (CDT) X-Face: \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO 5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed Reply-To: alk@pobox.com To: chuckr@picnic.mat.net Cc: chat@FreeBSD.ORG Subject: Re: swap-related problems References: <14101.3956.704332.389742@avalon.east> X-Mailer: VM 6.43 under 20.4 "Emerald" XEmacs Lucid Message-ID: <14101.7616.979211.817420@avalon.east> Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Quoth Chuck Robey on Wed, 14 April: : On Wed, 14 Apr 1999, Anthony Kimball wrote: : : > I disagree. The ability to produce a deterministic execution in : > compliance with the ANSI C standard is a Good Thing too. : : 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. No, this is incorrect: You are confusing failure modes. A portable, well-written program can recognize that malloc failed and take appropriate steps. : The only other difference is which signal kills your : program. No signal kills a program which handles out-of-memory gracefully, in an environment which support ANSI C semantics. : With memory overcommit, the chances of that program running : without errors, in full ANSI C compliance, are far, far higher. Right. I'm not arguing against memory overcommit. I'm arguing that an application should be able to enforce commit. : In order to stop that behaviour, you'd need to severely penalize all : other programs running on the system. No, you don't need to penalize anyone. Overcommit everyone else. Just let my very special and important program execute according to spec, please. : That'd be a wildly *unpopular* : feature, causing direct harm to most users, as their programs begin : failing much, much more often, due to unnecessary resource starvation. I think this is a bugaboo made of FUD. : Your statement above gives : folks the idea that we are ANSI C non-compliant, and for nearly all : situations, that's false. I disagree, to the degree to which compliance requires determinism. Well-written, portable code should be able to rely upon specified determinism. : It's only in the failure mode, when you are : running more programs than memory allows (including the large : magnification allowed by memory overcommit) that you even can tell a : difference. Compliant failure modes are *very* important. Being able to gracefully handle failure is very important. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message