If the loop is faster than 100ms (I would hope so), then the "read with chance of blocking" case should happen for each character.
In case it's unclear, the `pv -qL 10` limits the pipe throughput to 10 bytes per second: 1 byte per 100ms. On Tue, Oct 20, 2015 at 4:05 PM, Buck Evan <[email protected]> wrote: > There's no loop around echo: > > $ yes oh, hi! | pv -qL 10 | tai64n | s6-tai64nlocal > 2015-10-20 09:47:02.681071500 oh, hi! > 2015-10-20 09:47:03.493098500 oh, hi! > 2015-10-20 09:47:04.304479500 oh, hi! > ^C > > yes oh, hi! | pv -qL 10 | tai64n | tai64nlocal > 2015-10-20 09:47:44.813611500 oh, hi! > 2015-10-20 09:47:45.625627500 oh, hi! > 2015-10-20 09:47:46.436990500 oh, hi! > 2015-10-20 09:47:47.248335500 oh^C > > > > This prints slowly enough that I can *see* that tai64nlocal is printing > each character separately, but s6-tainlocal is printing per-line. > > > > On Tue, Oct 20, 2015 at 3:27 PM, Laurent Bercot <[email protected]> > wrote: > >> On 20/10/2015 23:36, Buck Evan wrote: >> >>> Is it expected that it's line-buffered? >>> >> >> It's not line-buffered. It's optimally buffered, i.e. the buffer >> is flushed whenever it's full (obviously) or whenever the loop >> goes back to reading with a chance of blocking. When you test >> with a loop around echo, you send lines one by one, so the >> behaviour appears to be line buffering, but that's only an >> artifact of your test. >> >> -- >> Laurent >> >> >
