Defer immediate reads

[kelunik]

Immediate reads have been introduced to support in-memory streams and STDIN on Windows, but this causes problems during piping of streams that always have data available, because it blocks everything else. This is resolved by deferring the promise resolution to the next tick.

[bwoebi]

While this is necessary, I am wondering though what it does to individual latencies. Especially if the OS has e.g. 256 KB in its buffer … with a default chunk size of 8192 we're now going to wait for 32 ticks until we can process that one batch of data.

It is generally favorable to batch-process data for latency (obviously, as long as the batch processed data is limited to a certain amount, avoiding the problem described here).

Therefore I do not like that change in this form. Especially considering that we're fixing a rather edge case here. It would perhaps be a good idea to allow up to X read() calls in one tick (perhaps 32) and only then defer. (and reset that counter in onReadable)

[kelunik]

@bwoebi That's what I previously did. We decided that it's probably not worth it. It's now the same latency as without #24. #24 has only been implemented to support Windows' STDIN.