Replies: 1 comment 1 reply
-
This was a mistake on my part, this wasn't fixed in the spec, this is intended and browsers have implemented it correctly so far. So right now it looks like this isn't going to change.
As far as I'm aware this is currently not possible. See WebAssembly/design#1162, I didn't read through it, so maybe you can find a gem in there. Also see whatwg/streams#757, the underlying JS issue. |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
As I understand, when working with WebTransport from WASM, the most efficient mode of operation would be to use a BYOB reader mode backed by a buffer that can be used from both within WASM and outside of WASM without transferring (i.e. copying) the backed memory across.
So, it seems like allocating an
&mut [u8]
and passing that as a buffer in WASM would work, but the browsers react to that poorly and take ownership of the whole wasm memory (and mess it up). This has already been discussed here. It is fixed in the spec, but the browser implementations for the update is not ready yet.So. What would be the most efficient way of using BYOB today, and once browsers finally implement the spec? Can someone come up with a code sample?
I currently simply do this: https://github.com/MOZGIII/xwebtransport/blob/1afc3c4fcb5c42e6546129d273b0b0c1b08b9f70/crates/xwebtransport-web-sys/src/lib.rs#L217-L231
This, however, will allocate two buffers instead of one: one has to exist at the caller code side and passed as
buf: &mut [u8]
to this fn, and another one would be allocated "inside" of thejs_sys::Uint8Array::new_with_length
call. The backed memory of these buffers would be separate, and thus we'd need copy the data over (withoutput_buf.copy_to
).Is it possible to get rid of the extra copy (i.e. the
output_buf.copy_to
) and make the underlying browser native code to directly write to thebuf: &mut [u8]
?Beta Was this translation helpful? Give feedback.
All reactions