Mail Archives: djgpp/1993/01/03/08:57:51
Amazingly enough Charles Sandmann 713-493-8756 said:
> OS/2 has an variable that is set in the config.sys file which indicates the
> minimum amount of free disk space which should be left when expanding the
> paging file. If the free space on the disk containing the paging file drops
> below that value, the paging file will not grow past that point. Additional
> requests for memory fail at that point (ie, malloc() returns NULL). This
> is really nice behavior, since you can configure the threshold as you want,
> and leaves enough disk space to recover from a bind (and signals the problem
> with the NULL pointer). There is also a function (a holdover from V1.x) which
> can be used to request the amount of free memory. This function under OS/2 2.0
> returns the amount of free RAM, not virtual memory. To be complete, you would
> probably want both - so you don't allocate huge amounts of workspace to speed
> up an algorithm and find out you spend all your time paging...
>
I like this idea!! A lot of this information is already kept track of by
the extender, I believe. It wouldn't take much to just query it before
processing the request. brk() and sbrk() should probably be responsible for
checking to see if the swap space is getting too large. Again, besure to
keep track of how much is currently is use, not just what ever the max was at
any given time.
Possibly the following functions:
coreleft() returns real+virtual left
swapleft() returns swap space left (either on device, or as limited by
a user option.
realleft() returns amount of realmemory left
All of this could be done with one turbo assist call. Maybe consolidated
to one actuall function call that that returns both real/virtual space left
and leave it as an excerise to the use to process the results of the query.
As an aside: When the first patches to let go32 run under dv came out,
there was a go32= option call -vcpi_limit that effectively limited the
maximum amount of physical memory go32 would use before starting to page
(ie, working set model). As I do almost practically all of my work from
inside desqview, I would love to see this option return (I don't think
it was ever part of the official djgcc release).
*sigh* I guess I'll have to reinstall turbo c and start playing around.
(anyone know of any probs with using turbo c++ 1.0, NOT 1.01, for building
go32? I never bothered upgrading because I started using djgcc exclusively
then. And yes, it was just djgcc then, not djgpp :-)
> As far as interrupt handling, there are two paths I am aware of. One is the
> TSR route, and the other is to modify GO32 itself. The event library is
> an example of the code imbedded in GO32, the async library the TSR approach.
> Since source code is available for both, I don't think there is any interrupt
> handling you couldn't do with modified copies of these two routines. GO32 is
> a DOS extender - so I think you have to be willing to get down to the DOS level
> (low and ugly) to do this sort of stuff. DJ and CB (and hosts of others) have
> been kind enough to provide us with their source code - great examples of how
> to do the hard stuff. I would encourage everyone with a difficult project to
> plunge in, understand how it works, modify it to meet your needs, and post it
> if it meets a general need! Ie, if you don't like DJGPP change it!
>
I'm of mixed emotions here. I think adding stuff to go32 proper needs to
be carefully thought out. We don't want to start eating into too much real
memory (specially for debug32. I hate running out of memory when reading
in a big source file).
Signal support should probably be supported in go32, but any other generic
interrups should go the way of TSR support.
more random ramblings,
mrc
--
Mike Castle .-=NEXUS=-. Life is like a clock: You can work constantly
mcastle AT cs DOT umr DOT edu and be right all the time, or not work at all
S087891 AT UMRVMA DOT UMR DOT EDU and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
- Raw text -