- From: Takeshi Yoshino <notifications@github.com>
- Date: Thu, 17 Sep 2015 05:56:16 -0700
- To: whatwg/streams <streams@noreply.github.com>
- Message-ID: <whatwg/streams/issues/318/141073197@github.com>
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