Date:	Thu, 28 Sep 2000 07:53:11 +0200 (IST)
From:	Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
X-Sender:	eliz AT is
To:	djgpp AT delorie DOT com
Subject:	Re: negative sbrk(0)
In-Reply-To:	<8qsaka$c3g$1@nets3.rz.RWTH-Aachen.DE>
Message-ID:	<Pine.SUN.3.91.1000928075251.12601D-100000@is>
MIME-Version:	1.0
Reply-To:	djgpp AT delorie DOT com
Errors-To:	nobody AT delorie DOT com
X-Mailing-List:	djgpp AT delorie DOT com
X-Unsubscribes-To:	listserv AT delorie DOT com

On 27 Sep 2000, Hans-Bernhard Broeker wrote:

> >>malloc only reserves the address space, but doesn't actually page
> >>in the memory until you access it.  (This is explained in section
> >>15.2 of the DJGPP FAQ list.)  So using malloc is indeed the right
> >>way of achieving what you want, even on memory-starved machines.
> 
> > What's the right way of achieving this on a HD-space-starved machine?
> 
> On a machine that's starved both of HD-space and of RAM, there's
> absolutely no way to run a program that wants to use, say 20 Megs of
> RAM at the same time. It's as simple as that. Memory space can't be
> generated from thin air, not even by DJGPP magic.

OTOH, if (as I understand) in this case the problem is how to process
a large file on machines with different amounts of installed memory,
perhaps the programmer shouldn't bother.  After all, paging is just a
kind of disk access (and quite an efficient one at that), so it isn't
worth the hassle (IMHO) to work hard just to replace it with another
kind of disk access, by e.g. processing the file in small chunks.

- Raw text -