I've said before that BYOB streams ( https://developer.mozilla.org/en-US/docs/Web/API/ReadableStreamBYOBReader) are extremely important for efficient consumption of Web streams from WebAssembly.
What I didn't realise is that the other way around applies, too: it's impossible to construct ReadableStream from a reused memory.
What I didn't realise is that the other way around applies, too: it's impossible to construct ReadableStream from a reused memory.
I'll use a Uint8Array backed by a regular ArrayBuffer here, but same applies to Wasm.
If you use normal start method and try to reuse same modified Uint8Array over and over, the object itself will be queued, without any internal copy, so any modifications will be reflected:
If you use normal start method and try to reuse same modified Uint8Array over and over, the object itself will be queued, without any internal copy, so any modifications will be reflected:
The closest way to reuse same backing memory I've found so far is combining `{ highWaterMark: 0 }` and a `pull` method. This allows to avoid an internal queue and modify the reused memory only when you know that the last chunk has been consumed:
Unfortunately, while this works for 90% of use-cases, where the chunk is consumed immediately, it won't work if the user decided to store chunks elsewhere to do something about them later:
Another alternative could be to use WeakRefs.
They're already at stage 3 in TC39, and would allow to track whether the previous chunk has been stored or consumed, and reuse it in the latter case. It's not clear which one will get stabilised first though. https://github.com/tc39/proposal-weakrefs
They're already at stage 3 in TC39, and would allow to track whether the previous chunk has been stored or consumed, and reuse it in the latter case. It's not clear which one will get stabilised first though. https://github.com/tc39/proposal-weakrefs
One thing pull method (even with WeakRefs) won't solve is Wasm memory growth.
When Wasm memory gets resized, it invalidates the existing ArrayBuffer, which, in turn, invalidates all existing views (chunks), too, making them empty.
For this, BYOB is the only reliable solution.
When Wasm memory gets resized, it invalidates the existing ArrayBuffer, which, in turn, invalidates all existing views (chunks), too, making them empty.
For this, BYOB is the only reliable solution.