bug#46388: 27.1; emacs -batch does not output messages immediately when invoked outside of the command prompt

[Ioannis Kappas <ioannis.kappas@gmail.com>]

> On 11 Feb 2021, at 14:09, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Ioannis Kappas <ioannis.kappas@gmail.com>
>> Date: Thu, 11 Feb 2021 08:10:34 +0000
>> Cc: 46388@debbugs.gnu.org
>> 
>>> My reading of the code is that we already fflush stderr after emitting
>>> a message, so this should already happen.  See message_to_stderr.  If
>>> that still doesn't help, then there's some buffering in the OS (for
>>> example, in the pipe machinery itself), which we cannot control.
>> 
>> the xdisp.c:message_to_stderr() is the first function i studied with
>> gdb when I started the investigation. Unless I've missed something,
>> it does not seem to lead to calling fflush (under windows at least):
> 
> Then maybe this:
> 
>> /* Return the error output stream.  */
>> static FILE *
>> errstream (void)
>> {
>>  FILE *err = buferr;
>>  if (!err)
>>    return stderr;
>>  fflush_unlocked (stderr);  <<<<<<<<<<<<<<<<
>>  return err;
>> }
> 
> should be fixed to fflush 'buferr' instead (or in addition to stderr)?
> 
> Paul, isn't that a bug that we fflush stderr here, and not 'buferr’?

(just a small note, “buffer" is NULL under windows, the fn thus returns without flushing anything. Even if buffer was not NULL, the fflush fn would have flushed the content of what ever has been accumulated on the stderr buffer so far, but not the message just  sent to message_to_stderr that we want to print out. Although, there would be this weird effect; message_to_sderr()  does an fwrite of the message followed by an fputc of a newline. This means that if errstream() was to fflush stderr, it would have flushed only the message written by fwrite, and not the newline written by fputc. I think that, if we are indeed considering to explicitly flush the message to stder, the correct place to do it would be directly inside the message_to_stderr(), thanks)