[fpc-devel] removed MaxAvail,MemAvail,HeapSize

[Konstantin Münning]

Florian Klaempfl wrote:
> Konstantin Münning wrote:
> 
> 
>>Hi everybody!
>>
>>Why in fact were MaxAvail,MemAvail,HeapSize removed from the RTL? The
>>explanation in install/doc/whatsnew.txt is puzzling me a bit:
>>
>>  - Removed MaxAvail, MemAvail, HeapSize due to their unreliability
>>    (bogus/misleading return values) in multitasking environment with
>>swapping
>>
>>Is the incompatibility of the source code preferred over a misleading
>>result? 
> 
> 
> In this case, yes. Better fail totally than under rare circumstance and
> hard to reproduce because the crashes are caused by a lack of memory
> causing strange behaviour of memavail in combination with new/getmem.
> 
> Keep in mind that the code
> if maxavail>=10000 then
>   getmem(p,10000);
> is completly useless in any multitasking environment.

In general speaking that's not true. What would be the replacement for
this? When you skip the check and allocate always then the program will
crash anyway when there is not enough memory. What would be the downside
of the bogus answer? If there was not enough memory when doing the
maxavail call but would have been on the getmem call then there would be
one "memory low warning" (or whatever an "else" condition action above
would be) more than really needed but how often would this "flaw" happen
in comparison to the crash without the check?

The only code I would say is really bogus with this is something like
getmem(maxavail) which would quite often fail without obvious reason but
it is a bad code for a multitasking environment anyway.

>>Such a major change should have a bit better explanation. I just
>>checked the FPC introduction that there is still the claim for
>>"excellent compatibility with TP 7.0" which seems I.M.H.O. now to be broken.
> 
> 
> How should work MaxAvail/MemAvail in a multitasking environment to be TP
> compatible?

It depends a bit on the assumptions you make about the environment. If
you assume that you have always any amount of memory (as would it be if
you skip the check) then it should return its max. possible value
(defining a constant will do).

I don't know exactly what value MaxAvail returned before on a Linux
system but returning in general the maximal allocatable memory by a
single allocation call at the moment of the MaxAvail call would be best.
The only problems to be expected would be on a system with a very low
memory where most programs would crash/abort/fail anyway or when trying
to allocate big chunks of memory. Big chunks for BP7 are 64KB. For
todays computers if there are no 64KB more memory left then this IS a
very low memory condition so this is not an issue for compatibility.

For allocating bigger chunks in a multitasking environment special
precautions must be taken anyway. I'm not aware of any standard function
which can guarantee this. I still assume that the failure of GetMem
causes a Heap-Runtime-Error like in BP7 so checking if the resulting
pointer is NIL is worthless ;-).

I don't know if the "best" operation described above is easily possible
as it may differ from the previous operation. In this case leaving the
original functions and putting a big fat warning in the docs about it
would be better than removing them. Printing warnings (like gcc does for
deprecated things) on compiling for the affected platforms is also a
good option but I don't know how easy this would be.

Just my 5 cent.

How do you allocate memory in a fashion that is suitable for all
environments?

>>I understand that this may lead to strange behaviour of a program but
>>wouldn't it have been better to include a remark in the documentation
>>than to remove the function(s)? So it would be programmer's choice to
>>leave it or to change it to something appropriate for the environment of
>>the program.
>>
>>So, what are now the options? What are the recommended replacements for
>>these functions? What's the best way to make working programs to compile
>>again?
>>
>>By the way, there are still references in the RTL, the examples and the
>>docs to these now missing functions. Some seem to have been missed on
>>cleaning ;-).
>>
>>Have a nice day,
> 
> 
> 
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel