On 23 mei 2005, at 11:09, Konstantin Münning wrote:
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.
Yes, by trying to allocate that memory. There is no other way that I
know of.
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.
No, because they do not crash if it fails. They simply return an error
which you can check. And this error is consistent. There are no cases
where you do not get an error, but that the allocation failed
nevertheless (or vice versa).
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.
These old programs "think" they are checking for errors, but in
practice they are not.
And as to buggy programming - what can you really do when a getmem
fails?
That completely depends on the program. A game will probably terminate
with an error, our compiler will terminate with a run time error and a
server app will probable reject a new connection or terminate the
current session.
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!?
Reset and rewrite also have other functionality. The compiler nor the
RTL can enforce proper usage of file locking semantics, just like it
can't force you not to have any dataraces.
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.
The compiler never checks whether enough memory is left. It will simply
terminate with a run time error if no memory is left anymore.
The HeapStatus stuff can also not be used to query how much "free OS
memory" (whatever that may be, see my previous list of possibilities)
is left. It can only tell you how much memory has been allocated to the
program, how much of that memory is actually in use etc.
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.
There is no "better" function afaik (other functions will simply
require more work to implement, but the end result will be pretty much
the same).
Jonas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
