[streams] Generalized and precise flow/buffer control (#301)

Before recent redesign, we always had a queue in the JS world behind a readable stream, and we calculated how to exert backpressure to the "underlying source" based on the size of the queue.

We're now separating the streams API semantics visible to the consumer (mainly implemented in the reader) and a queue behind it which doesn't always exist (depending on who (JS, C++ code, kernel, device, etc.) buffers data). This made me think more generally, that is, there're many points of buffering behind streams. The number of such points depends on which API we're using, which platform we're using, etc.

It sounds like both the high water mark & strategy concept, and the precise flow control stuff I proposed only make sense for streams with a queue in JS world. It seems it's hard to well-define `queueSize`, `highWaterMark`, `pullAmount`, etc. as cross-platform, cross-API feature.

To put it differently, for non-JS-queue-backed APIs, what do we guarantee for the consumer when HWM is set to X?

I still guess some kind of best-effort approach is still useful. The UA tries to keep the number of bytes buffered on the path between the ultimate data source (disk, the peer server, etc.) and the JS world. As Domenic originally suggested, the strategy itself should be chosen intelligently by the UA considering memory size, CPU power, browser architecture, etc. etc. and it's responsible only for computing how much data is buffered in **the JS world**. Combining buffer size info (C++, kernel, JS, ...), the UA would intelligently limits the amount of data to pull.

And, the `pullAmount` or something in the proposed precise flow control APIs will just give a hint about how quickly the consumer can consume data in the form of the number of bytes. It is not directly connected with such as the size of the queue in JS. The stream utilizes the info using some algorithm to control amount of data to pull.

---
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/301

Received on Wednesday, 18 March 2015 05:35:23 UTC