Re: [streams] Should we "lock" readable streams while piping? (#241)

I didn't even think about writable stream :-/.

After sleeping on it, I think it is OK to duplicate the interface. The way @tabatkins phrased it was:

- Readable streams are normally only consumable via piping
- For lower-level exclusive access (via read()/ready/state), use a Reader.
- However, we can add convenience versions of read()/ready/state on to ReadableStream for people who don't want to be bothered.

If we make that clear in the documentation, it feels OK. I'm not sure if it'll affect the spec or implementation strategy.

The remaining issue in my mind is exactly how we create these reader objects. [My spike](https://github.com/whatwg/streams/blob/lock/reference-implementation/lib/experimental/exclusive-stream-reader.js) follows [your suggestion](https://github.com/whatwg/streams/issues/241#issuecomment-61126402), which is pretty clever. However, I made a tweak in the last commit that makes it easier for custom stream implementers. For example let's say I want to do something like

```js
class InstrumentedReadableStream extends ReadableStream {
  read() {
    const chunk = super.read();
    console.log('chunk!', chunk);
    return chunk;
  }
}
```

In your design, any reads made through the lock would not trigger the instrumentation, since it delegates directly to ReadFromReadableStream. With my tweak, it delegates to `this.read` after temporarily unlocking the stream, which means that custom overriden reads work.

---

Overall I am feeling better about this. A few minor issues we should think about:

- Can we refine the setup so that the code inside getExclusiveReader() is not so full of boilerplate?
- The name might not need "exclusive"; that could be left implicitly understood.
- Should we add .closed to the reader too? Probably, I think.
- Is it a good or bad idea to try to flip the implementation along the conceptual lines earlier in my message? For now it is probably a bad idea since creating a lock is a relatively heavyweight operation, but maybe if we tweak the implementation it can be a simple object allocation without much complicated setup, which sounds possibly acceptable?
- My setup in https://gist.github.com/domenic/d421643d95cdec9a9b5b#file-readable-stream-locks-2-md, if properly extended to ready/state as well, was kind of simple. It's similar to the current situation except it uses a shared weak set to let the reader access the stream, instead of having the stream hand the reader those capabilities at creation time. I am curious how implementers feel about the two different approaches.

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