From owner-freebsd-current  Wed Apr 14  6:17:22 1999
Delivered-To: freebsd-current@freebsd.org
Received: from kot.ne.mediaone.net (kot.ne.mediaone.net [24.218.12.203])
	by hub.freebsd.org (Postfix) with ESMTP id C0CA01570E
	for <current@freebsd.org>; Wed, 14 Apr 1999 06:17:20 -0700 (PDT)
	(envelope-from mi@kot.ne.mediaone.net)
Received: (from mi@localhost)
	by kot.ne.mediaone.net (8.9.1a/8.9.1) id JAA24946
	for current@freebsd.org; Wed, 14 Apr 1999 09:14:35 -0400 (EDT)
From: Mikhail Teterin <mi@kot.ne.mediaone.net>
Message-Id: <199904141314.JAA24946@kot.ne.mediaone.net>
Subject: Re: swap-related problems
In-Reply-To: <366.924075434@critter.freebsd.dk> from Poul-Henning Kamp at "Apr 14, 1999 09:37:14 am"
To: current@freebsd.org
Date: Wed, 14 Apr 1999 09:14:35 -0400 (EDT)
X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w<gv/&E-lL7twZCT8B~/PA4|\t$ti+22K">
	 hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli"<kcG^EOVih
	 y+z3/UR{6SCQ
X-Mailer: ELM [version 2.4ME+ PL49 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-freebsd-current@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

Poul-Henning Kamp once stated:

=>Well, this is just an implementation detail, is not it? I don't
=>mean to critisize, or anything, but such thing as "no available
=>memory" is a fairly intuitive... Coming down, again, the malloc
=>should return a usable memory if available and NULL if it's not.
=>Is not this a "natural" semantics? Why can a program die because
=>_another_ program ate up all the rest of the memory?
=
=You know, this strikes me about as productive a discussion as the
[...]
=Very very fundamental to UNIX philosophy is the maxim that it is
=roots responsibility to configure the system right.

I'm sorry I managed to annoy you. However, a program needs to be
able to know if it can legally ask for more memory, right? And it
is "very fundamental to malloc philosophy", that malloc returns
NULL, when it can not get more memory. Which it apparently does
now on FreeBSD, but only if the program exceeds an artificial
datasize limit...

And if it is not set, it the administrator's problem? May be...

Should we, perhaps, have it documented in a number of places,
including malloc(3)?

My other problem with the artificial limits, is that I can only
specify the absolute figures. Besides an ability to use Mb, Gb,
Kb, I'd like to have % there... And, as I mentioned before, an
ability to distribute the class database over NIS...

	-mi


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message