-
Notifications
You must be signed in to change notification settings - Fork 1.7k
fix: make the logs line buffered #9496
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Oh, I didn't even realize that was our logging sink. I'm surprised it behaves like this, since it's already using a Anyway, #9274 will probably get rid or replace that code. |
Oh, it's |
Yeah, I actually checked stderr, I think that's the main issue. |
TIL: rust-lang/rust#64413 Let's just quickly fix this by formatting the string to memory with |
Can we wrap stderr in a |
I've done the same for the Logger in this PR. or you mean for the whole source code? |
49b15d3
to
799ec79
Compare
self.no_buffering | ||
|
||
if self.no_buffering { | ||
self.flush(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
self.flush(); | |
w.lock().flush(); |
(or better, hoist that to a local).
Then flush
is dead code.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well we can't remove flush as it's part of Log trait.
Instead, I will put the actual flush inside of it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, sorry, I missed that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not to be too nit-picky, but this feels strange -- what if log
calls flush
internally?
I would have left flush
unchanged, moved w.lock()
to a variable, then called flush
on that in this branch.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess what you're suggesting makes sense, that way we had to acquire the lock twice.
5977848
to
9815835
Compare
self.no_buffering | ||
|
||
if self.no_buffering { | ||
writer.flush().unwrap(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe
writer.flush().unwrap(); | |
let _ = writer.flush(); |
But I'm not sure how I feel about it. This might cause some spurious panics when we're run by another program and it closes our stderr
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, I only put the unwrap() to get rid of the warning. thanks for mentioning.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, then maybe let's ignore the errors here.
9815835
to
2ad6985
Compare
2ad6985
to
60e304c
Compare
bors r+ |
fixes #9432
Not quite sure if that's what you want, but storing the log message in buffers eliminated the tiny write syscalls for me.
I just changed the Logger struct.