[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Paul Eggert
Subject: Re: `message' not outputting the newline "atomically"
Date: Sat, 6 Jul 2019 18:16:03 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.2

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

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.

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]