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

I tried to prototype your idea in a bit more detail at https://github.com/whatwg/streams/blob/lock/reference-implementation/lib/experimental/exclusive-stream-reader.js. I am still uneasy about how much we are duplicating the stream interface here. Unsure what to do about it.

> It might be useful if closing a stream unlocks it implicitly. Then we don't need to proxy .closed.

This would require the stream to track any locks it creates. Certainly doable, but adds a bit more complexity. Unsure if there's much gain either in preventing multiple consumers from seeing that the stream was closed or became errored.

---

I wonder if there is a simpler design we can use that doesn't require a new object that parallels the stream API. One idea would be something like

```js
var lock = stream.lock();
stream.read(lock); // works
stream.read(); // throws
lock.release();
stream.read(); // works now
```

This is kind of nice since the code stays entirely within the ReadableStream class. However I don't know how to solve this for the getters, lol -_-.

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