From:	mcastle AT cs DOT umr DOT edu
Subject:	Re: Packing go32 into an .exe
To:	peprbv AT cfa0 DOT harvard DOT edu (Bob Babcock)
Date:	Fri, 1 Jan 93 15:06:11 CST
Cc:	alane AT wozzle DOT linet DOT org, djgpp AT sun DOT soe DOT clarkson DOT edu

Amazingly enough Bob Babcock said:
> >[crash when swap disk full]
> >2. Yes that is still true, but frankly, all DOS extenders that I know
> >of that support VM have that property -- what would you have it do?
> 
> Windows 3.1 and OS/2 give me virtual memory.  If I try to malloc too much,
> malloc returns NULL.  I can then save work-in-progress, and maybe shell out
> and free up some disk space.  It's also nice to be able to tell how much
> (virtual) memory is left so that you can save your work before you hit a
> crisis.  Otherwise, you may find that you can't do a save because opening a
> file takes some memory for buffers.  I agree that you are in trouble if it
> gets to the point of having no swap space when a page fault occurs, but I
> would think that this need not happen if the memory allocation routines can
> get information about the swap space.
> 

It's not the malloc() that causes the swap space to fill.  Remember, the 
memory is never actually allocated until ACCESSED.  So, you can have a
4meg swap area, and malloc an 8meg array with plans on accessing only 
a few elements (sparse array).  But if you decide to access more area 
than you have swap space left, you run out of swap area on a memory access,
not on the call to malloc().  

I thought os/2 also provided a similiar functionality (this is demand paging,
right?).   If so, does os/2 set a limit on how much memory can be requested
by each task?  

I imagine it would be fairly simple to teach malloc to return NULL on a
request for more than 256Megs, but that's the only thing I see fixable.

Actually, you *could* probably write a coreleft() function.  Instead of
checking phsical memory, you check the amount of diskspace left on the
swap device (figuring out how to do this from Eric Backus' port of 'df'
should be fairly easy).  Only problem with this is, I don't think go32
shrinks the swap file as memory is freed, so it's possible for the swap
file to be much larger than the actually memory being used.  I suppose
you could modify malloc() and free() to keep track of the total memory 
allocated and compare this with the size of the swap file and doing some
calculations.   Perhaps using calloc() or intializing the variable 
right away to avoid the sparse array problem and checking with your coreleft()
would be a good plan of attack?

just some random thoughts,
mrc

- Raw text -