Jonas Maebe wrote:
On 23 mei 2005, at 02:29, Konstantin Münning wrote:
What would you suggest to return under an OS like Windows, Mac OS X or
Linux? The current "free" memory of the OS? Free memory + buffer cache
- minimal buffer cache size enforced by the OS? The previous +
available swap space - "wired" (i.e., not swappable to disk) memory?
Just a constant? Something different possibly?
I have written in my previous mail(s) that I think the best return value
would be the biggest value with which a getmem would be successful if
memory conditions haven't changed inbetween.
The only way to know that is to perform getmem's with every increasing
values until one fails.
I was not implying that a getmem(maxavail) must work under any
circumstances on a multitasking OS. But as the OS knows at a given point
what the maximum availible memory for a single allocation call is, so
could a program running on that OS.
Most programs work most of the time except under heavy load. That's not
a good argument.
I beg you pardon? I think the argument that most programs do not work
well under heavy load is an extremely bad argument to encourage even
more buggy programming.
Please don't understand me wrong - I don't encourage the use of these
functions. I'm only speaking about compatibility to old code which was
there and is now missing.
But back to the argument - as on a multitasking system ANY memory
allocation could fail at ANY time, if this was so severe, none of these
OSes should be accepted by the community as they are buggy. But as you
see everybody seems to live happily with this as the chances these
failures to happen are acceptable low. So allowing old programs
initially designed for other environments to "live" with the same
limits, that's OK I think.
And as to buggy programming - what can you really do when a getmem
fails? Even doing fancy tricks with exceptions and such will not help.
If you haven't added some "own" memory management (like garbage
collection) to free some "unneeded" memory in such a case there are only
two things you can do - wait until there is the requested memory
avalable and allowing by this your program to hang indefinitely or fail
in some more or less informative way. Show me one program which can run
without the required memory and does not fail in any way. Are you still
considering it buggy programming?
Please let it be the programmers choice
what to do and how to handle this.
Only using tools that make sense, everything else would be snake oil
(and in reality nothing would be handled).
A compiler should be providing the
means, not taking them away.
It should not provide known defunct means.
It's not the means but the way you are using them. Would you then remowe
the Reset/Rewrite functions as well? In many (old) programs they are
used to check for presence of file(s) to prevent overwriting by first
trying to open them and if this fails then the file can be written...
But as in a multitasking environment the file can appear just between
the Reset and the Rewrite - well, bad bug. There are the means to do
this right by the proper OS functions so maybe this should be enforced
as well!?
(I hope I haven't brought you to another "imrpovement" idea ;-))
Anybody writing a program knows that there
may be flaws.
No, if you use RTL routines, you expect them to work.
(see above)
A warning (with an advice how to make it better) should
still be the best for this.
People don't read the manual.
Well, then they maybe will not know about the existence of the function
:-). Still a compiler warning for deprecated functions would be nice.
{$ifdef HASGETHEAPSTATUS}
status:=GetFPCHeapStatus;
startmem:=status.CurrHeapUsed;
{$else HASGETHEAPSTATUS}
startmem:=memavail;
{$endif HASGETHEAPSTATUS}
I'm not sure if I understand it right as GetHeapStatus is not documented
well (I've found no reference for the meaning of the fields of the
returned record) but it seems that someone repaced here memavail with
another code which does about the same and has therefore the same flaw.
The above code is not used to check whether there's still enough free
memory left, it's only used to calculate how much memory is used by the
compiler.
I just picked one.
I would hapily contribute the code for a better MemAvail/MaxAvail
function if that's the problem. I would like to be able to use the
latest compiler which now I definitely can't as I must have the BP7
compatibility which is very good in 1.0.10.
You can make a unit which contains a dummy memavail and maxavail which
always return a value of 1GB or so, then your program will also always
work except under heavy load (if that is really what you want). There's
no use in investing lots of time in making very complex routines to
query all sorts of information from the OS and then have it fail in
exactly the same circumstances as when you return a plain constant.
I mentioned the plain constant alernative in one of my first mails as it
depends on the assumptions you make. Its about compilability of old code
and this would also do but a better function would reduce the
unavoidable failures to a minimum.
The -So loading of a compatibility unit is probably the best solution here.
Konstantin.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
