Re: [whatwg/streams] pipeTo(): the stream queues should be used (#653)

> My first implementation for Chrome didn't start a read() until the previous WritableStreamDefaultWriterWrite() had finished. It was totally compliant and passed all the tests, but had exactly this problem.

I see. So what we really want is some suggestion that you read ASAP, using only the "backpressure must be enforced" signals instead of any other signals.

Here would be my spec phrasing. I would nest it under "Backpressure must be enforced":

- After taking into account these backpressure signals, reading and writing should be done as fast as possible; other signals should not be used to delay the continual reading/writing.

  EXAMPLE: An implementation that waits for each write to successfully complete before proceeding to the next read/write operation violates this recommendation. In doing so, such an implementation makes the internal queue of _dest_ useless, as it ensures _dest_ always contains at most one queued chunk.

> What do you think? Is it reasonable to expect every implementation to pass this test, or is it okay for an implementation to deliver <64 in this case?

I think it's probably reasonable to expect it to pass "eventually". Codifying that in a specific test (e.g. do we give them a grace period?) will be a bit tricky. But I think it's reasonable to adopt an approach of adding such a test, adding a code comment that it tests a "should" requirement, and seeing if anyone complains.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/653#issuecomment-273629736