From: bwhite AT inmet DOT camb DOT inmet DOT com (Bill White)
Subject: Re: Virtual memory and malloc()
To: djgpp AT sun DOT soe DOT clarkson DOT edu
Date: Fri, 5 Jun 92 17:46:58 EDT

Micheal Thomas writes:
...
>  What is the benefit of getting the NULL returned over having the Fatal
> Error? (perhaps, being able to save some information before dumping out of
> the program?) either way the program isn't going to work, because you are 
> out of memory? Both cases you are going to have to tell the user that they
> need more disk space? I guess I'm asking what are you going to do once
> you have the NULL?
> 
There are alot of applications where you set up big data structures with
alot of redundancy in order to help you search a space quickly.  For
example, you might represent a relation several times, sorted on several
components.  If a program runs out of memory, it might decide to reclaim
some of the redundant representations and run in a degraded fashion.

If you are running a program which has some control responsibilities, say
a program which controls some piece of hardware, you want the control
program to decide how to die, since it might decide to reinitialize itself,
or else to shut the plant down.  Of course, anybody who wrote critical 
real-time software using gcc deserves to be shot.

The gcc suite of tools attempts to emulate the Unix environment.  In
Unix there are software settable limits on the amount of space you can
use.  That is, if you allocate until you run out of memory, you can
choose when you will run out of memory before you start your program.
This can be emulated in a gcc program with a runtime parameter to your
program.

Of course, we didn't pay for it, did we?

					Peace,
					Bill White

P.S. I think it is interesting to notice that go32, the dos extender,
is a little OS kernel which provides system services to the program
which it extends.  In this sense it is like the Unix kernel.  One might
imagine implementing a go32 "call" which does what the setrlimit system
call does.  However, there is only one Unix kernel, and there may be 
many instances of go32.  These instances must all share the swapping 
resource, and this sharing is the source of the trouble.  Multiple
instances of go32 are synchronized well enough to allow each other to 
make memory allocate properly atomic, but they don't give global
information, such as "how much swap space is left."  (How does go32
do this, anyway?  Does each program get its own swap space, relying on
DOS to synchronize them?)