Re: [whatwg/streams] Efficient mapping to Unix-style APIs with pollable readers and writers (Issue #1265)

I would hope that native code would use an abstraction layer on top of `poll`, `read` and `write` which would make it easier to adjust the semantics. That's what Chromium's network code does.

Maybe we can just say "if you don't use an abstraction layer, you're going to get extra copies and you'll just have to accept it"?

> * a new peek() method which returns a Promise that resolves when there is data in the internal queue or the underlying source has indicated that there is data available.

Sketch: we add an optional peek() method to the underlying source. It is called when `reader.peek()` is called with nothing in the internal queue. The underlying source returns a promise which resolves when a synchronous read is expected to succeed. If the underlying source does not implement `peek()` then the streams machinery falls back to calling `pull()`.

Bikeshed: "peek" usually implies you get to look at the data before reading it. That would be a lot of trouble. Maybe instead have a getter called `pending` or something, so you could do `await reader.pending`?

> a sync: true option to read() which will cause it to return a ReadableStreamReadResult rather than a Promise<ReadableStreamReadResult> if there was data in the internal queue or the underlying source responded to pull() by enqueuing a buffer synchronously. Otherwise it would return null or some other sentinel value.

If we use the same method name, then we have to set the return type to `any` which means we don't get the nice WebIDL magic for handling promises.

I would prefer to have a distinct method which does this, maybe `readSync()` or `readNow()`. It should probably throw a specific exception if there isn't any data available synchronously.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/streams/issues/1265#issuecomment-1497115261
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/streams/issues/1265/1497115261@github.com>

Received on Wednesday, 5 April 2023 08:29:37 UTC