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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden
> Date: Thu, 27 Jun 2019 13:03:17 +0200
> 
> Eli Zaretskii <address@hidden> writes:
> 
> > Sorry, I've probably misunderstood what was being discussed.  I thought
> > you were talking about the conversion itself.  The target string is of
> > course created via xmalloc.  B ut that could hardly infloop.
> 
> So, that function is a function that will commonly already call xmalloc,
> so adding another one doesn't substantially change the guarantees or
> behaviour of that function, which was my point (because that's the
> `message' path).

Each additional call increases the risk you will run out of memory or
hit some calamity.  It isn't an all or nothing situation.

> The practical problems with interleaving (that is, the only ones I see
> with any regularity) are the ones that stems from using `message' in a
> batch Emacs, and the other uses of stderr aren't problems in practice.
> (Because they're only used for errors that "shouldn't happen".)
> 
> But I'm all for fixing those things if that can be done in a way that
> doesn't break anything, and then (of course) the `message' path could
> also use that machinery.

I'm okay with making 'message' write in one go to stderr, but I don't
want to pay the price of having stderr buffered globally.  Several
solutions for this single issue were already proposed, but we keep
rejecting them and returning to line-buffering time and again.  I
think if we want to solve the original problem, that of 'message' in
batch sessions, we should stop looking for a 110% perfect solution,
and certainly not try to solve additional issues while we are at that.