Re: [streams] [Reader] Should resolve readyPromise on getReader() call? (#258)

When reading the lock system, I came up with alternative that is to switch the target promise of each algorithm (e.g. `read()`). Discussed with @yutakahirano and summarized the ideas.

When lock is not in use, `[[readyPromise]]` is exposed via `ready` getter. In the current design, `read()`, etc. works on `[[readyPromise]]` even after a lock is created.

In the alternative approach,
- we stop accessing `[[readyPromise]]` once a lock is created. If the stream was `"waiting"` before locking, it stays to be `"waiting"`, and the promise obtained via `readableStream.ready` before locking stays to be pending.
- we create a new promise and expose it on the reader which represents current status of the stream
- once the stream is unlocked, `read()`, etc. again operate on `[[readyPromise]]`. If the stream was closed, errored, or became readable, that will be applied to `[[readyPromise]]` on unlocking.

To make this work, we need to introduce a new state in addition to current locked/unlocked states. Currently, the stream is unlocked by the reader on each operation. For the stream, it's indistinguishable whether it's unlocked temporarily for reader to run some operation, or it's unlocked as there's no reader associated with the stream. So, `readableStream.read()`, etc. cannot switch between the two target internal slot to hold a promise. We need to make it distinguishable.

There's no need to introduce state variables to represent the states. We should instead make `readableStream.getReader()` and `reader.releaseLock()` do something special.

This may conflict with some of the design philosophies listed in the Locking... md file. We'll investigate feasibility of this design tomorrow.

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