Yes, basically all buffering should use work-or-time based flushing.
Work-based flushing exists to batch work to amortize overhead. It allows you to tune how much time you spend in overhead in a work period. However, this can result in unbounded delay.
Time-based flushing targets a worst-case latency in low throughput environments. This ensures you do not get unbounded delays. Interestingly, this also allows you to tune how much time you spend in overhead in a work period.
So, with work-or-time based flushing what you are really tuning is how much time you are willing to spend in overhead in a work period and balancing that against latency.
As a nit, the article calls this a derivative of Nagle’s algorithm, but it is basically the opposite. Nagle’s algorithm is about batching until acknowledgement with no mention of time. In fact, the lack of time-based flushing in Nagle’s algorithm is why it interacts so poorly with TCP Delayed Ack.
abecedarius 3 hours ago [-]
> flush the buffer if it’s been idle a short time
I've thought this was the right default for a good while. 50 years ago when Unix was designed, maybe not.
wpollock 4 hours ago [-]
In C, you can use setvbuf to control buffering on stdout. There are also Linux command line utilities you can use to control buffering, unbuffer and stdbuf.
usefulcat 3 hours ago [-]
This is true, although neither of those by them selves will achieve what the author is aiming for.
cowlevel 47 minutes ago [-]
This would withhold a line if the writer paused for a while without calling into buffer code. Another case for Golang supremacy?
We can also do better than terminals. 7-Zip was the GOAT.
Rendered at 21:20:54 GMT+0000 (Coordinated Universal Time) with Vercel.
Work-based flushing exists to batch work to amortize overhead. It allows you to tune how much time you spend in overhead in a work period. However, this can result in unbounded delay.
Time-based flushing targets a worst-case latency in low throughput environments. This ensures you do not get unbounded delays. Interestingly, this also allows you to tune how much time you spend in overhead in a work period.
So, with work-or-time based flushing what you are really tuning is how much time you are willing to spend in overhead in a work period and balancing that against latency.
As a nit, the article calls this a derivative of Nagle’s algorithm, but it is basically the opposite. Nagle’s algorithm is about batching until acknowledgement with no mention of time. In fact, the lack of time-based flushing in Nagle’s algorithm is why it interacts so poorly with TCP Delayed Ack.
I've thought this was the right default for a good while. 50 years ago when Unix was designed, maybe not.
We can also do better than terminals. 7-Zip was the GOAT.