Re: [streams] Support reading bytes into buffers allocated by user code on platforms where only async read is available (#253)

@tyoshino

> If consume() sees rs becoming closed, or consume() is called on a closed stream, filledView with byteLength === 0 is returned.

I think it should still return `ReadableStream.EOS`, not an empty buffer.

> no locking. obtain stream from source. pipe is on source. pipe gets stream and returns on completion.

I don't like this. I think streams, including piping, should be able to stand on their own.

I think we can do locking with (A) as long as we don't try to make the semantics too complicated. That is where I got stuck in #288.

Hmm. Although I just had a new thought. Maybe what you are suggesting is basically the same as the following, just from another point of view:

- "Readable streams" have pipeTo and pipeThrough methods, and probably a closed promise, and *maybe* a cancel() method. But they do not have a direct read() method.
- "Readable streams" let you get "readers" which have direct read() methods. (Maybe readers should have the rest of the readable stream interface too. Or maybe not.)

I think this is isomorphic to what you are saying if we replace your "byte source" with my "readable stream" and your "readable stream" with my "reader". From that point of view the essence of your proposal is that we remove read() from ReadableStream itself and only give it to the reader. That seems actually pretty good to me.

> queue lives in source. not in stream.

This could be an implementation choice for some streams, but not for others.

> Class definitions

I guess release() here makes sense because your version has readable streams taking the role that readers used to have.

Let me try to outline the class definition I am thinking of:

```js
class ReadableStream { // fetch.body might be an instance or subclass of this
  get closed()
  cancel(reason)
  pipeTo(dest, options)
  pipeThrough(pair, options)
  getReader()
}

// class ReadableByteStream has the exact same interface as ReadableStream (yay!)
// but its getReader() returns a ReadableByteStreamReader and its pipeTo is
// maybe optimized to take advantage of that

class ReadableStreamReader {
  get closed()    // maybe
  read()
  cancel(reason)
  releaseLock()
}

class ReadableByteStreamReader {
  get closed()    // maybe
  read(view)      // note difference
  cancel(reason)
  releaseLock()
}
```

@yutakahirano

> I'm trying to describe pull()'s abstract behavior (for option (C) + always manual RBS).

Hmm. This is pretty convincing that async pull() + read() is complicated. The issues like 

> A stream may become readable without fulfilling all pending promises returned by multiple pull calls.

are kind of scary.

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