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

[Paul Eggert]

Eli Zaretskii wrote:

> One way of fixing message3_nolog and vmessage would be to use in them
> that additional line-buffer stream you defined in your patch.

That would be easy enough to do; see the attached patch. However, although it's 
good to fix the problem for these two functions, we should also fix the problem 
where it occurs elsewhere. Please see below for more about this.

> > As the above example shows, it's quite possible to output more than what
> > GNU/Linux fprintf does. So, if "as much as possible" is a hard
> > requirement, Emacs must stop using fprintf to format diagnostics like
> > the above.
>
> I meant as much as possible by just using fprintf.

I expect that's not precisely what you meant, as it's quite possible to just use 
fprintf to output more than what Emacs currently would do if Emacs had a serious 
bug in its error-printing code. For example, we could write our own printf-like 
function that does its actual work via 'fprintf (stderr, "%c" C)' where C is the 
next byte to output. That would just use fprintf for I/O, and on GNU/Linux it 
would output more than what we're doing now, for hypothetical buggy code such as 
the example I gave.

What I *think* you meant is that you want code that outputs diagnostics 
conveniently, via functions like 'fprintf' and 'message' and 'fatal' etc., to 
output as much as possible within the constraints of (a) not significantly 
obstructing convenience and (b) fixing the line-interleaving bugs somehow.

I could be wrong, though.

> I was certain what I wrote will not be interpreted
> in this way.

I'm afraid that you were mistaken there. Even now I'm not sure I understand 
exactly what you meant. It is an area where it's tough to be precise.

> using the above for diagnostic output, or for informative
> messages output during an Emacs build, is unrelated to the original
> problem raised by Lars.  That problem was with messages from a running
> Emacs, outside of the build process (because the build process use
> case can be handled by the Make's -O switch), i.e. when Emacs is run
> as part of some script.

Sorry, I'm not following you here, as Lars's original email 
<https://lists.gnu.org/r/emacs-devel/2019-06/msg00710.html> was about messages 
generated by Emacs running inside the build process.

We cannot rely on 'make -O' to address the problem, as 'make -O' slows down 
development, which is why I typically don't use 'make -O' and don't recommend it 
for building Emacs interactively. 'make -O' can be useful for buildbots where 
there's a batch process that waits for build completion before publishing it. 
However, under an interactive Emacs where I want to act on the first diagnostic 
right away (before the build finishes), 'make -O' is a net minus because it can 
delay diagnostics significantly, and this delay costs more than it's worth.

And even if we assumed 'make -O' sufficed for builds (which it doesn't), we 
can't assume these diagnostics are generated from a single instance of GNU Make. 
It's reasonably common, for example, that from a terminal window I'll run the 
shell command "emacs &", and then do other stuff in that window while Emacs 
occasionally outputs stderr diagnostics. (Although I think this is the sort of 
thing you're alluding to above, I'm not sure.) So we would have an interleaving 
problem anyway even if 'make -O' worked well.

> I reviewed the list, and I think only message3_nolog and
> vmessage need to be changed.  All the rest are fatal error messages
> and debugging diagnostics of sorts, and quite a few of them even
> conditioned by some CPP symbol that is only defined in debugging
> builds.

Unfortunately even fatal error messages and debugging diagnostics can be output 
in circumstances such as the above, and so can be interleaved confusingly. So 
the other items in that list still need fixing. Plus, there are other 
interleaved-I/O problems not in that list; as I mentioned, the list is only 
partial. So the attached patch does not suffice to fix the problem.

0001-Avoid-interleaving-stderr-in-a-few-cases.patch
Description: Text Data