From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: negative sbrk(0)
Date: 27 Sep 2000 08:20:26 GMT
Organization: Aachen University of Technology (RWTH)
Lines: 43
Distribution: world
Message-ID: <8qsaka$c3g$1@nets3.rz.RWTH-Aachen.DE>
References: <8qprpe$l72$1 AT diana DOT bcn DOT ttd DOT net> <Pine DOT SUN DOT 3 DOT 91 DOT 1000926162008 DOT 13268V AT is> <9612ts0ut4p6970tnng7n1a7qd8452odq0 AT 4ax DOT com>
NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de
X-Trace: nets3.rz.RWTH-Aachen.DE 970042826 12400 137.226.32.75 (27 Sep 2000 08:20:26 GMT)
X-Complaints-To: abuse AT rwth-aachen DOT de
NNTP-Posting-Date: 27 Sep 2000 08:20:26 GMT
Originator: broeker@
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Damian Yerrick <Bullcr_pd_yerrick AT hotmail DOT comremovebullcr_p> wrote:
> On Tue, 26 Sep 2000 16:35:23 +0200 (IST), Eli Zaretskii
> <eliz AT is DOT elta DOT co DOT il> 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.

There's a reason that virtual memory is called 'virtual', see? It's
sometimes (usually) there, but sometimes it won't be. And if it isn't,
no-one's going to help you against that.

If an application really wants to run on machine that has no more
than, say 10 Megs of RAM + swap space free for DPMI applications, then
it's in the responsibility of the *programmer* to ensure that it never
uses more than 10 Megs, at any time.  Given that there are so many DPMI
servers that either refuse or are not able to report reliable figures of
how much memory will be available, this leaves roughly two choices:

1) make it runtime-configurable by the user.
2) do all the memory management yourself, by never doing more than one
   single, huge malloc(), at the beginning of the program. Hand out 
   portions of that by your own malloc() substitute function. The 'big'
   malloc can start with what dpmi_report_free_memory_information(),
   try to allocate all of it, and walk down from there until it
   gets a successful malloc(). Or it can be a series of as many 'large'
   succeeding calloc() calls as the system will grant, before it starts
   reporting out of memory. You risk breaking libc functions that want
   to use malloc() themselve, by this strategy, though.



-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.