HN

Comments (5)

• Veserv
  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
  > flush the buffer if it’s been idle a short timeI've thought this was the right default for a good while. 50 years ago when Unix was designed, maybe not.
• Menu

  wpollock
  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.
• cowlevel
  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.