Re: `message' not outputting the newline "atomically"

[Eli Zaretskii <eliz@gnu.org>]

> Cc: schwab@suse.de, larsi@gnus.org, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Sun, 23 Jun 2019 01:34:05 -0700
> 
> Eli Zaretskii wrote:
> > What if Emacs crashes half way through that loop
> 
> What, due to a hardware error or a buffer overrun or something like that? In 
> that case all bets are off: Emacs could output nonsense or truncated output 
> regardless of whether it uses one system call or a hundred.

Diagnostic output is precious precisely when "all bets are off".  For
example, knowing that the loop did N iterations and died on (N+1)st or
later can give a very important clue about the cause of the crash.

> Besides, if we were allowed to hypothesize nonexistent bugs to argue against a 
> change to Emacs, then we could easily argue against any change whatsoever. When 
> thinking about changes to Emacs, it's more productive to consider real problems 
> than imaginary ones.

Bugs aren't hypotheses, they actually happen.  And stderr is one
facility to diagnose abnormal behavior.  Changing the buffering mode
of a diagnostic stream globally because of a specific use case is
therefore a bad idea.

> Line-buffered stderr does a better job of interleaving diagnostics from parallel 
> instances of Emacs, and this is what prompted the fix in question.

Once again, the primary purpose of stderr is to produce diagnostic
error messages, so the producing nicer output is much less important
than producing as much of the output as possible.

> The poorly-interleaved diagnostics have been a practical problem
> that has bugged me for a while, and bugs Lars and I assume
> others.

That use case could have a more specialized solution, such as explicit
control of buffering from Lisp or a variant of 'message' that writes
to a different stream.  There's no need to juggernaut a
general-purpose facility for the benefit of a specific use case, and
not a very important one at that.