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

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: eggert@cs.ucla.edu,  daniele@grinta.net,  emacs-devel@gnu.org
> Date: Wed, 26 Jun 2019 11:15:54 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > There was no reason to rush this to the repository.  Paul raises valid
> > concerns, some of which I had as well.  Also, the commit message
> > describes something that is very different from the code that was
> > actually pushed.
> 
> The commit message talked about interleaved outputs, which is exactly
> what the patch tries to fix, so I'm not quite sure what you mean here...

The commit message mentions PIPE_BUF etc., something that was
discussed, but is not in the code.

> > There's also a possibility to use the null byte that we
> > always/normally have in strings after the last byte.  'fwrite' doesn't
> > need it, so we could replace it with a newline, write the message,
> > then replace the newline back with the null byte.  This is somewhat
> > hacky, but it eliminates the need for a buffer and a loop.
> 
> That's an intriguing idea.  But is there a possibility that the fwrite
> would fail in such a way that we'd not get back control in such a way
> that we could guarantee that we could replace the newline with a null
> byte again?

How would that happen?  If fwrite crashes, we are going down in flames
anyway, so no one will have the opportunity to miss that null byte.
Any other failure means fwrite returns with an error code, and we then
put the null byte back as usual.

> Especially in a multi-threaded Emacs...

With the current "concurrency" feature, only one thread can run at a
time, and the thread which called this code cannot be
interrupted/preempted until it returns, because fwrite doesn't cause
us to yield.  In some distant future, when Emacs is really
multi-threaded, all bets are off, because we do such stuff in more
than one place.