emacs-devel
[Top][All Lists]
Advanced

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

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


From: Daniele Nicolodi
Subject: Re: `message' not outputting the newline "atomically"
Date: Tue, 2 Jul 2019 22:56:05 +0200
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.7.2

On 02/07/2019 08:47, Eli Zaretskii wrote:
>> Cc: address@hidden
>> From: Daniele Nicolodi <address@hidden>
>> Date: Tue, 2 Jul 2019 09:58:34 +0200
>>
>> On 01/07/2019 20:28, Eli Zaretskii wrote:
>>>> From: Daniele Nicolodi <address@hidden>
>>>> Date: Mon, 1 Jul 2019 19:01:18 +0200
>>>>
>>>> I think you didn't understand my point, and your selective quoting makes
>>>> me thing you are trying to warp what i wrote in your favor. I was
>>>> arguing that in the case of a fprintf() with a format string that ends
>>>> in a new line there is no way to obtain a partial output, with stderr
>>>> unbuffered or line buffered. On any sane implementation of the c library
>>>> Either you will get it all or nothing.
>>>
>>> And I was saying that this is wrong.  With unbuffered stderr, you
>>> _can_ obtain partial output.
>>
>> I still disagree.
> 
> Then maybe you should have a look at the implementation in the various
> libc's out there.  In all those I looked at, fwrite, fprintf,
> etc. call fputc or its moral equivalent to emit every single character
> they produce; they rely on the lower-level buffering layer to DTRT
> regarding buffering.  IOW, none of the functions that write to FILE
> stream pay any attention to the newline.  In particular, using fputc
> for every character means that in an unbuffered stream each character
> will be immediately written out, modulo the low-level device-specific
> buffering in the OS.

I agree.  I would like to stress the "modulo the low-level
device-specific buffering in the OS" part.

>> Can you please write a piece of C code that achieves that, having a
>> fprintf() function call error out, in whichever way you prefer, such
>> that it's output is partial? I tried to achieve that myself and I
>> haven't found a way.
> 
> See one such example below.  The effect might be system-dependent, but
> it crashes in the middle of output for me both on GNU/Linux and on
> MS-Windows.

Great!  Thanks!  Have you verified what is the _minimum_ length of the
output for which you get truncated output vs no output at all?  On my
system it is 1024 characters (and I think that this value is fairly
standard, on the small side if anything).

So the only circumstance in which we would end with no output in the
case of the line buffering, but some output with no buffering is if the
string we are printing is longer than 1024 characters.  This does not
change if the line contains newlines.

Funnily, if the printf() output is less of 1024 characters but contains
newline characters, full lines are printed in case of line buffering,
but nothing is printed in case of no buffering.  It seems thus that if
the median message printed on stderr by Emacs less than 1024 characters,
line buffered stderr is actually allowing Emacs to dump more output on
the terminal than unbuffered stderr  :-)

PS: stdbuf from coreutils is very handy for those tests.

Cheers,
Dan



reply via email to

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