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

Thanks for the review @tyoshino; sorry I didn't get a chance to pass it by you earlier. 

> lock.isActive looks useful as Yutaka said (#241 (comment)) but I also wonder if there's any concrete use case where this is required (not just useful).

Yeah, maybe we should remove it until someone asks for it?

I guess part of the reason I have it is that it's better to avoid forcing people to use try/catch. I can't think of a real world situation where you would, but it seems nicer to be able to do

```js
if (reader.isActive && reader.state === "readable") {
  console.log(reader.read());
} else {
  console.log("not locked!");
}
```

instead of

```js
if (reader.state === "readable") {
  try {
    console.log(reader.read());
  } catch (e) {
    console.log("not locked! or maybe another error?", e);
  }
}
```

> releaseLock() maybe to make it more descriptive, you've included Lock. Right? Just release() would have any problem?

I said releaseLock() since usually the variable will be `reader`, not `lock`. I.e., `reader.releaseLock()`. I also think this is a bit helpful to differentiate operations that pass through to the stream (like `read()` and `cancel()`) versus ones having do to with the reader and the lock it has acquired. Just `release()` sounds too similar to `cancel()` for me.

> Even after release, reader's closed, ready, and state getters will simply delegate to the encapsulated stream as the note at https://streams.spec.whatwg.org/#reader-release-lock explains. I don't have strong opinion yet but wonder if this is useful or harmful.

I at first had a design where they would fail but it turned out to be quite hard to write `pipeTo` correctly in that design, because `pipeTo` consults those properties a lot. For example in the design where closing a stream automatically releases any held locks, the check `source.state === "closed"` never works since by the time it's closed `state` becomes a throwing getter. If I recall even in designs without auto-release-on-close there were other problematic cases as well. So I think it is pretty useful in the end.

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