Re: [streams] Maybe giving async readInto (and read?) another shot (#290)

In #libuv IRC @indutny was kind enough to explain to me one use case for readInto that came up in io.js TLS stream work. Apparently OpenSSL has its own set of buffers that you are meant to put data into, where it will get encrypted. In JS terms, he did

```js
socketStream.readInto(openSSL.putStuffInThisBuffer, ...)
```

Without readInto, he would have had to allocate a new buffer, then copy it into `openSSL.putStuffInThisBuffer`. This is beyond the fragmentation problem from my gist. Rather, it's a constraint imposed by the library you're using (in this case OpenSSL).

You could imagine a JS library that behaves in a similar way. However, it's not too plausible... it's unclear what the benefits of a library disallowing bring-your-own-buffer in that way would be.

And even if it were plausible, there's no way we can accommodate it with our restriction against observable data races :(. Maybe if Mozilla convinces everyone to add [SharedArrayBuffers](https://docs.google.com/document/d/1NDGA_gZJ7M7w1Bh8S0AoDyEqwDdRh4uSoTPSNn77PFk/edit#heading=h.a6o4dubw5qla) to the platform.

Maybe we should not bother with readInto because the use cases for when you'd want to use it and also deal with the transferring are too rare? We could even add the transfer version later if we find a use case for it.

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