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: Stefan Monnier
Subject: Re: `message' not outputting the newline "atomically"
Date: Mon, 24 Jun 2019 00:09:57 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

>> Seeing none of the 32 bytes of fingerprint instead of only seeing the
>> first N of them seems like a very minor inconvenient.
>
> See my other message: seeing the full output could be priceless.

Maybe in some hypothetical scenario.  FWIW this kind of thing never
happened to me, wheres garbled output is something I've seen at least
once a week.

> Besides, with the current buffering mode you might not see any of the
> bytes at all.

Yes, that's what I said.  And I'm perfectly fine with that.

If you think the output of each byte is important, you can add `fflush`
in the loop, of course.

> (Not that this is a very important example, but I didn't invent it.)

In my experience buffered-but-not-printed output is only a problem if
the programs gets to another place in the code, such that the lack of
output leads you to believe the code hasn't yet reached that code when
in fact it's already further.
If it crashes in the middle, the actual output doesn't matter: the
debugger will immediately tell you where the program was.

>> Buffering can indeed be harmful, but only when significant
>> computation/time can pass between the `fprintf` and the moment the
>> corresponding text is "displayed", which is not the case here (nor
>> anywhere else in Emacs's C code, according to my quick "grep stderr").
> The time has no influence on this, because no stdio implementation
> I've seen flushes buffers based on time since the last output.

It's significant when as a user you expected the output to appear
a while ago and it hasn't appeared yet (it leads you to build up
a flawed model in your head of what the program is actually doing).
In my experience, this is the situation where buffering makes debugging
painful.

In the present case this is not an issue because the \n is printed right
after and causes a flush.

>> > So this looks like a net loss to me.
>> I don't have a strong opinion on this, but FWIW, I see a net gain and no
>> significant loss.
> I see a net loss.

Yup, we disagree ;-)


        Stefan




reply via email to

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