Latency-bounded reads

[nidhijaju]

Many media-related use cases complain that there's a lot of overhead from unnecessary wakeups from read(), as streaming network reads use too much CPU and power. They would benefit from latency-bounded reads i.e. "try to fulfill read() once, 10ms from now, with all the data you've received between now and then".

In addition to min in https://github.com/whatwg/streams/pull/1145, it might be good to have something like deadline as an option for read() to allow for latency-bounded reads.

cc @ricea

[saschanaz]

Can the purpose be fulfilled by something like pull(c) { c.enqueue(data); return new Promise(r => setTimeout(r, 10)) }? Another pull won't happen until the promise resolves, right?

[ricea]

Can the purpose be fulfilled by something like pull(c) { c.enqueue(data); return new Promise(r => setTimeout(r, 10)) }? Another pull won't happen until the promise resolves, right?

This doesn't help with platform streams like Response body.

[saschanaz]

Hmm yeah, #616 could allow TransformStream based control:

stream.pipeThrough(new TransformStream({
  transform(chunk, c) {
    c.enqueue(chunk);
    return new Promise(r => setTimeout(r, 10));
  }
}))

For now this only works for non-BYOB readers, so the usefulness is limited for byte streams.

[MattiasBuelens]

I don't think this can be solved in the underlying source. Your example adds a 10ms delay between each chunk, whereas the OP wants to add a 10ms delay between each read(view). That single read(view) could be populated with bytes from multiple chunks, if the view is large enough and the deadline has not been hit yet.