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

[Paul Eggert]

On 6/20/19 11:06 AM, Eli Zaretskii wrote:
> But GNU/Linux does start with it unbuffered, or else the code to make
> it line-buffered wouldn't be needed, right?

Yes, and it turns out that I was misinformed about what "unbuffered" 
means in GNU/Linux. I thought "unbuffered" (_IONBF) meant completely 
unbuffered, i.e., that individual 'write' system calls need to be done 
for each byte of output. But although POSIX allows this, it does not 
require it; all that's required of _IONBF is that writes must be done 
"as soon as possible", a term POSIX does not define. GCC+glibc takes "as 
soon as possible" to mean that by the time that (say) printf has 
successfully returned, a sequence of 'write' system calls has been done 
that implement the printf output; this is typically more efficient than 
completely unbuffered, since it means (for example) that printf ("x=%d", 
42) can be implemented via write (1, "x=42", 4) rather than via four 
one-byte 'write' calls.

In contrast, GCC+glibc takes line buffering (_IOLBF) to mean that a 
'write' system call is needed whenever printf etc. outputs '\n' (or 
whenever the output buffer is full of course).

POSIX allows stderr to default to any kind of buffering other than 
_IOFBF (fully buffered). This is similar to POSIX's treatment of the 
default buffering for stdin and stdout when they are interactive devices 
(noninteractive stdin/stdout must be fully buffered).

In GCC+glibc, neither _IOLBF  nor _IONBF strictly dominates the other in 
terms of buffering. That is, there are examples like where _IONBF 
buffers more than _IOLBF, and vice versa. It is counterintuitive that 
unbuffered output can buffer more than line-buffered output does, but 
there it is.


> I think we do want it to be unbuffered, so that important error
> messages are output in their entirety, or as close as possible.
Every important Emacs stderr message ends in newline, so there's no 
significant practical difference between _IOLBF and _IONBF on that 
score. And _IOLBF has a practical advantage: it causes stderr output to 
interleave better with the output of other processes. The problem of 
interleaving has bugged me for a while (long before Lars pointed it 
out). In some cases the interleaved output can be pretty hard to 
decipher. Although _IOLBF does not fix all the problems with interleaved 
output from Emacs, it should fix most of the problems I run into.