[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: Wed, 26 Jun 2019 11:27:45 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.7.1

Eli Zaretskii wrote:
a version with a fixed-size automatic buffer and a loop using
it to write the message in chunks, would be a much cleaner solution
than allocating the buffer off the heap.

Yes, that would be an improvement. I see other issues with the current master. It doesn't fix output-line interleaving on AIX or Solaris in places where GNU/Linux works OK, as AIX and Solaris fprintf functions are less buffered (i.e., they commonly split Emacs output into 'write' calls that are smaller than a line), which means that common fprintf output can be interleaved on AIX and Solaris when it is not interleaved on GNU/Linux. Also, the current master mishandles the rare case where the string has INT_MAX or more bytes, and also mishandles line-interleaving if the string contains newlines.

Like Lars, I'm leery about temporarily trashing the representation of a Lisp string in order to do I/O. There will likely be other places where we need to do this sort of thing, but where the data are not in Lisp strings. It's not that hard to efficiently output even a very long Lisp string without modifying it, so let's do that.

Proposed patch attached. This defaults to line buffering on glibc as well as on AIX and Solaris, as I've verified that glibc buffers appropriately and have used it pretty extensively with Emacs.

Attachment: 0001-Avoid-interleaving-stderr-lines.patch
Description: Text Data

reply via email to

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