[fpc-devel] ConsoleIO and flushing buffered output

[Michael Van Canneyt]

On Mon, 8 Jun 2020, Tomas Hajny wrote:

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

That is why I said 'could'. I didn't intend to change anything.

Michael.