On 2020-06-08 11:39, Michael Van Canneyt wrote:
On Mon, 8 Jun 2020, Christo Crause via fpc-devel wrote:
.
.
Thanks for your response Michael. Using InOutFunc to also flush the
output
buffer will work, but that seems inefficient, since the flush needs to
wait
until the transmit buffer is empty (at slow UART speeds this could
potentially take several ms to complete). Is there a specific reason
why
the RTL Flush procedure does not call the FlushFunc method?
I checked; That code is so old, no idea.
From what I can see the flush code could be changed to
if Assigned((TextRec(t).FlushFunc) then
FileFunc(TextRec(t).FlushFunc)(TextRec(t))
else
FileFunc(TextRec(t).InOutFunc)(TextRec(t));
But keep in mind that the InoutFunc() is only called when actually
writing
data, meaning: when the internal text buffer is full or on a terminal
with
every writeln(), so I don't think it is inefficient. Writeln() will do
a
flush. Whether this happens in .InOutFunc or .FlushFunc is largely
irrelevant.
The question is whether the potential change would make any difference.
IMHO, the important points are:
1) The point of flushing is making sure the I/O is really performed (the
data are sent to the operating system _and_ flushed from internal
buffers of the underlying operating system / platform). Doing the latter
without the former makes no sense.
2) From semantic point of view, all data should be sent to the final
place (block device / console / ...) before the call to Flush is
finished (otherwise the following actions may have incorrect results -
the program might finish before all data are transmitted, other I/O may
be invoked, etc.).
From this point of view, the proposed change would only lead to code
duplication between FlushFunc and InOutFunc and / or to increased code -
e.g. checking FlushFunc being nil before calling InOutFunc just to call
InOutFunc (or to perform functionality currently included in InOutFunc)
from within FlushFunc anyway.
Tomas
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
