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 WebTransportSendStream and WebTransportReceiveStream be transferable? #424

Closed
jan-ivar opened this issue Oct 6, 2022 · 4 comments · Fixed by #433
Closed

Should WebTransportSendStream and WebTransportReceiveStream be transferable? #424

jan-ivar opened this issue Oct 6, 2022 · 4 comments · Fixed by #433
Assignees

Comments

@jan-ivar
Copy link
Member

jan-ivar commented Oct 6, 2022

For almost a year, between #307 and #395 (nevermind #423), the following streams were transferable streams:

let {readable, writable} = await wt.createBidirectionalStream();

writable = await wt.createUnidirectionalStream();

for await (readable of wt.incomingUnidirectionalStreams)

But right now they're not, since "Platform objects can be transferable objects if their primary interface is decorated with the [Transferable] IDL extended attribute."

Q: Should they be? This would allow .getStats() to be called where data is read and written, as well as make this allowed:

const wt = new WebTransport(url);
const {readable, writable} = await wt.createBidirectionalStream();
sendWorker.postMessage({writable}, [writable]);
receiveWorker.postMessage({readable}, [readable]);

If we don't then the above will fail, and apps would have to work around it like this instead instead:

const wt = new WebTransport(url);
const wts = await wt.createBidirectionalStream();
const sendable = new TransformStream(), receivable = new TransformStream();
sendable.pipeTo(wts.writable);
wts.readable.pipeTo(receivable.writable);
sendWorker.postMessage({sendable}, [sendable]);
receiveWorker.postMessage({receivable}, [receivable]);
@aboba
Copy link
Collaborator

aboba commented Oct 6, 2022

I was hoping to avoid the pipeTo workarounds you describe. For example, being able to transfer the readable stream wt.incomingUnidirectionalStreams would be helpful.

@aboba
Copy link
Collaborator

aboba commented Oct 7, 2022

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.

On main thread it does seem possible to construct a WebTransport, build a 'complex' readable or writable stream based on it, and then transfer those streams to (distinct) workers. However, so far the performance seems quite bad and it crashes the tab.

Sample (which reliably crashes the tab after pressing stop): https://webrtc.internaut.com/wc/wtSender6/

@ricea
Copy link
Contributor

ricea commented Oct 7, 2022

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.

@jan-ivar
Copy link
Member Author

Meeting:

  • Seems fine. No objections

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants