Mail Archives: djgpp-workers/1996/07/28/03:42:27
> If leaving CWSDPR0 alone doesn't impose any burden, I say leave it there.
It's no problem, just two commands to build it from the same sources.
It's just a question of whether it is still useful at all or not.
> (with any luck, this could just happen within 5 hours of releasing r3 ;-).
Ack! Reason enough!
> How about an environment variable
No environment variables. Maybe a command line switch.
> that, when set, will cause CWSDPMI to
> print on exit all kinds of statistics about the client?
Might be useful. Maybe a single line summary.
> Maximum memory usage, number of page faults, internal CWSDPMI memory usage
> (to give a clue on how close one is to exhausting the CWSDPMI heap)--anything
> that can be of any use. That should make diagnostics a lot easier.
None of those things are currently tracked :-)
The heap usage is difficult, since you have a hard time figuring out what the
stack usage was. R3 should just fail the dpmi memory call, so you may end up
with only 26Mb of memory allocated if you use small pieces. In my test
suite there is now an image which does 32K mallocs until NULL is returned.
I can tell when I have r2 in my path, since it pagefaults instead of exits...
R3 has the largest number of changes since like beta7 or something. It's
got the list of things done that should have been in R1. Oh well.
- Raw text -