[fpc-devel] removed MaxAvail,MemAvail,HeapSize

[Jonas Maebe]

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