From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/213 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: holywar: malloc() vs. OOM Date: Mon, 25 Jul 2011 15:21:41 -0400 Message-ID: <20110725192141.GP132@brightrain.aerifal.cx> References: <20110724103325.GA24069@albatros> <20110724124034.GI132@brightrain.aerifal.cx> <20110724182533.GB6429@albatros> <20110724221907.GL132@brightrain.aerifal.cx> <20110725174343.GB4462@albatros> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1311622364 9670 80.91.229.12 (25 Jul 2011 19:32:44 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 25 Jul 2011 19:32:44 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-297-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jul 25 21:32:39 2011 Return-path: Envelope-to: gllmg-musl@lo.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by lo.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1QlQtL-0000zf-1O for gllmg-musl@lo.gmane.org; Mon, 25 Jul 2011 21:32:39 +0200 Original-Received: (qmail 5426 invoked by uid 550); 25 Jul 2011 19:32:38 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 5415 invoked from network); 25 Jul 2011 19:32:38 -0000 Content-Disposition: inline In-Reply-To: <20110725174343.GB4462@albatros> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:213 Archived-At: On Mon, Jul 25, 2011 at 09:43:43PM +0400, Vasiliy Kulikov wrote: > Rich, > > On Sun, Jul 24, 2011 at 18:19 -0400, Rich Felker wrote: > > Any system without this guarantee is a TOY, nothing more. I'm aware > > that the default sucks, > > I don't think the default sucks, it is just targeted to other programs. I disagree. I think the default discourages writing safe, robust applications (people always say "Why should I check the result of malloc? It will return success then crash later anyway because of overcommit.") and encourages writing broken hackware that depends on the availability of overcommit. > Think about Java/Python programs, which request hundreds megabytes, but > using only tens of them. This is not a valid way to write applications. It's basically the same as the classic joke about Windows 95 containing: if (rand()%1000==42) bsod(); I'm also a bit unsure how a Java or Python program would allocate hundreds of megs but leave them completely untouched. Usually HLL's dirty memory as soon as they allocate it with initialization, object construction, etc. so I'm doubtful your example has anything to do with the real world... > Also daemons with fork() model being able to > handle hundreds/thousands connections actively using COW would not be > able to fully exploit COW potential. As long as the main daemon (prior to accepting connections) does not use much memory, it's not an issue. If it is an issue, just throw in an extra hard drive that's always spun down with a few TB of swap space and the commit allowance will go through the roof. Also, if you'll be calling exec after fork, posix_spawn is available as an option. On a good implementation, it can/will use vfork or some other clone variant to avoid increasing the commit charge in the window between fork and exec. Rich