Could a byte stream read directly into and out of a SAB (w/o transfer)?

[lukewagner]

It would be really great if wasm could read from a stream directly into its memory. The backing ArrayBuffer of a WebAssembly.Memory cannot be detached (nor would you want to since it holds the general program state needed for execution in the meantime) so what would be great is if the caller of a read or write could pass a typed array view of a buffer that is not detached. For a regular ArrayBuffer, this would mean some additional copying to avoid races. However, if the buffer is a SharedArrayBuffer, then perhaps it would be fine to expose the races (and no worse than anything else with SAB).

As an additional benefit, I think the implementation of "read into a view" from a file-backed stream could use mmap to make a copy-on-write mapping of the file directly into the target memory.

(cc @flagxor)

[ricea]

There was some discussion of SAB with streams previously here: #495 (comment)

It seems likely that we will add a way to use a SAB without transferring. Unfortunately it doesn't look like we will get the nice memory protection semantics that would let us avoid data races. I'm not concerned about exposing data races to wasm, since C++ programmers already live in a world of races. I feel it's unfortunate to expose it to Javascript.

[lukewagner]

Ah, I see, so should I keep this issue open for this specific request or is it a dup of #495?

[ricea]

I think this is useful as a separate issue. I've marked it with Milestone V2 to reflect that it's not something we'll be changing immediately.

[domenic]

I think we should change this sooner rather than later. In Blink we're behind on implementing byte streams, but others have done so, and should be able to get these benefits---especially if we have interested consumers in the wasm space. Plus, I believe right now the spec is incoherent, as it tries to transfer SharedArrayBuffers, which causes a spec-level assert failure.

I do think it's sad that this exposes data races, but I also agree that SharedArrayBuffers in general broke that seal, and we should integrate with them rather than wishing they didn't do that.

I'll try to work on this when I get done with TC39 and some other work items...

[ricea]

If in future we'd like TextEncoderStream's readable side to be a byte stream then we have a conflict here. It's undesirable for user code to be able to view the encode in progress, because it may be using vector ops or other things that are browser-specific. There are probably going to be other cases of platform streams where we'd like to prevent intermediate values from being visible.

I think all solutions involve adding an extra copy when the output is a SharedArrayBuffer. The question is whether this copy becomes part of the ReadableStream machinery that is specified by a flag, or whether the underlying source has to detect that controller.byobRequest.view is an SAB and do the copy itself.

[lukewagner]

Talking to @vasilvv today in the context of WebTransport using whatwg streams and how that kind of use case could perform optimally when used with wasm: in addition to the advantages identified above, the new API could potentially use a callback design (instead of promises) where the SAB-view and callback were registered once and then reused throughout the duration of the stream, so that there was, by design, without engine heroics, zero garbage generated per packet/chunk.

[ricea]

I don't think we're likely to add callback-based APIs. Eliminating the promise from the external API wouldn't eliminate the promise returned from pull(), nor the other objects that are created internally. The objective of "zero garbage" isn't achievable without engine heroics anyway, so I don't see a compelling reason to add APIs that don't align with the rest of the standard.

[lukewagner]

From what I've heard from @vasilvv, there's a lot of overhead with the current approach, enough to be problematic for APIs considering using them, so perhaps more cross-cutting changes could be justified with the goal of not creating garbage on each chunk, given that performance is the point of the lower-level API.