Re: [streams] Port precise flow control to writable streams (#318)

I was supposing cases where:
- We're piping data from ReadableStream R to WritableStream W
- There's a producer P behind R
- There's a consumer C behind W
- R has a queue RQ
- W has a queue WQ
- When P sees new space available in RQ, starts producing more data to fill it. But it takes some time to produce it.

When the amount of data in WQ decreases a little, i.e. desiredSize increases, we should immediately tell that to RQ so that P can start producing more data.

This argument supports (4).

(5) is useful when:
- a producer code is directly using the WritableStream. the producer can tell the size of the next item
- we want to strictly limit the size of the queue in the WritableStream

(3) and (4) work but we can reduce number of notifications by (5).

> (Remember, we are just trying to decide the default for waitForDesiredSize(), or whatever it is called.)

Oh, OK. Then I slightly prefer using (1) for `.ready` and `waitForDesiredSize(undefined)` for the same reason as above.

But as you wondered in the second paragraph for different topic, if our sizes are non-integer, the behavior cannot be realized by `waitForDesiredSize(n)`. It strikes a little weird to me though it's not a big deal. n = Number.EPSILON? Hmm.

> I think you can get (4) with writer.waitForDesiredSize(writer.desiredSize + 1)

Yeah, right.

> Given this I propose: writer.waitForDesiredSize(n = high water mark), i.e. default to (2). This will fulfill when desiredSize becomes >= min(highWaterMark, n).

Ah, ... I think I'm fine with this, too.

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

Received on Thursday, 17 September 2015 12:56:44 UTC