Re: [streams] Support reading bytes into buffers allocated by user code on platforms where only async read is available (#253)

Thanks for the summary > @tyoshino 

I now prefer async read to pull + sync read, because of the following reasons.

1. If there is one-to-one correspondence between pull and read calls, it is essentially async read.
1. Otherwise, it is hard to define getReader. As I wrote below, I want to decouple pending read operations and the lock behavior, but I couldn't think of any reasonable rule determining if there is a pending read except for counting calls.

I like OperationStream because of the ease of reader-writer pair construction, but I need to think more.

Detacghing:

ArrayBuffer.transfer is not yet specified and we need a workaround for a while.

For async read, providing read(size) and not providing read(bufferview) seems reasonable.
For writing, Is is OK to copy the given buffer when we can't write the buffer to the sink synchronously?
For the latter case, we need a note that it is not safe to touch the passed buffer after calling because it will be detached after ArrayBuffer.transfer is defined.

Locking:

> 1. s.getReader() fails if there's any pending read() operation.
> 1. s.getReader() causes any pending read() operation to stay pending until release, at which time it re-polls the queue
> 1. s.getReader() doesn't affect pending read() operations.

My preference is 3 > 1 > 2. Same for releasing.

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