Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should incomingUni/BidirectionalStreams be "owning"? #507

Open
jan-ivar opened this issue May 4, 2023 · 2 comments
Open

Should incomingUni/BidirectionalStreams be "owning"? #507

jan-ivar opened this issue May 4, 2023 · 2 comments
Labels
Waiting-for-feedback Waiting on requested input or feedback

Comments

@jan-ivar
Copy link
Member

jan-ivar commented May 4, 2023

From #424 (comment) and #424 (comment):

Attempting to transfer wt.incomingUndirectionalStreams doesn't appear to work, as you say. When getReader() is called on the transferred readable stream of streams, the error is A ReadableStream could not be cloned because it was not transferred.

Sorry about this. Currently when a stream is transferred, the chunks that are passed through the stream are always cloned, never transferred. Since incomingUnidirectionalStreams is a stream of streams, each chunk is a stream, and streams can only be transferred, not cloned.

There was a plan to also support transferring the chunks (see Future Work) but without a concrete use case it never proceeded to the design stage.

whatwg/streams#1271 adds a new "owning" ReadableStream type, which allows for transferable chunks, albeit for a different purpose.

@ricea would making incomingUnidirectionalStreams and incomingBidirectionalStreams "owning" solve the DataCloneError, or is that a different part of the spec?

@wilaw wilaw added the Discuss at next meeting Flags an issue to be discussed at the next WG working label May 5, 2023
@ricea
Copy link
Contributor

ricea commented May 8, 2023

Currently the "owning" logic isn't wired up to the transferable streams logic. Once that is done, then it should work.

@jan-ivar
Copy link
Member Author

@ricea Do we have an issue open for that? Would it be different from whatwg/streams#1124?

@wilaw wilaw added Waiting-for-feedback Waiting on requested input or feedback and removed Discuss at next meeting Flags an issue to be discussed at the next WG working labels Aug 14, 2023
@wilaw wilaw added this to the Future version milestone Mar 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Waiting-for-feedback Waiting on requested input or feedback
Projects
None yet
Development

No branches or pull requests

3 participants