[fpc-devel] removed MaxAvail,MemAvail,HeapSize

[Florian Klaempfl]

Konstantin Münning wrote:

> 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? 

Try to allocate and check if it worked or let the heap manager throw an
exeception if it can't allocate the memory.

> When you skip the check and allocate always then the program will
> crash anyway when there is not enough memory. 

With the check the chances are only less that the program crashes but it
can still do so. So your program is still buggy.

> 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?

See above.