Re: [streams] ReadableByteStream underlying source/controller design: return a promise vs. c.something (#354)

```
const underlyingByteSource = {
  pull() {
    c.close();  // When this should be issued???
    return Promise.resolve('foo');
  },
  cancel() {
  }
}
```

If `close()` is a separate method, we need to issue it after the last chunk is handled by the stream. We can wait for another `pull()` and `close()` in it, but it means we require one more microtask delay and bother the user by asking one-action-per-one-pull.

```
const underlyingByteSource = {
  pull() {
    return Promise.resolve({value: 'foo', done: true});
  },
  cancel(reason) {
  }
}
```

We can choose to fulfill the promise with a tuple containing a "done" signal.

Suppose there's a microtask (call this task-A) that runs `reader.cancel()` already queued in the task queue when the current task that is now calling `reader.read()` and resulted in `underlyingByteSource.pull()` call.

Even if the `pull()` returns a resolve promise immediately, the function to handle the fulfillment value of the promise (cast if necessary) returned by `pull()` is run after the task-A is run. Then, the underlying byte source receives `cancel()` call though it already told the stream that it's "done".

We kinda said it's okay for this issue and adopted promise based result returning for WritableStreamAdvanceQueue (here, the race with "abort" was the problem).

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