Repository navigation
List of issues to discuss with TC39, WASM, JS engine teams #747
Description
Activity
Non-transferable ArrayBuffers (mapped ArrayBuffers shouldn't be transferable to other threads). (We can do this without JS changes by faking transfers, by making them actually copies instead.)
SharedObjectTablea bit likeSharedArrayBufferbut instead of containing bytes, they contain references to shallow-cloneable objects ([Serializable]IDL interface objects). This should allow for example forGPUTextures created on one worker to be instantly visible to other workers.
Reacted by Kai Ninomiya, Thomas Debesse and Lv YitianWebCodecs is also interested in read-only ArrayBuffers, for providing access to YUV planes in CPU memory that remain owned by decoders. Is there any previous work on this request?
Reacted by Dzmitry Malyshau, Linz, Lv Yitian and SurajA discussion on the internal-gpu mailing list can be found here:
https://lists.w3.org/Archives/Member/internal-gpu/2020May/0001.html
in which Ken discusses Java's past experience with read-only ArrayBuffers.
I just forwarded it to you, @sandersdan.Other discussions I just found:
Reacted by Dan Sanders, Linz and Lv Yitian- Re-pointing an existing ArrayBuffer wrapper to a new backing store (to avoid garbage) (EDIT: ResizableArrayBuffer proposal would allow us to achieve this)
- Detachable SharedArrayBuffer, for mapping a buffer and then accessing the mapping from multiple threads
SharedObjectTablea bit likeSharedArrayBufferbut instead of containing bytes, they contain references to shallow-cloneable objects ([Serializable]IDL interface objects). This should allow for example forGPUTextures created on one worker to be instantly visible to other workers.
It turns out that this (or synchronous receive-message) would also be extremely useful to WebAssembly for sending modules around for dynamic linking.
Reacted by Lv YitianAnother important thing to discuss with TC39 is adding a concept of non-transferrable
ArrayBuffer. Right now this group agreed to make the result ofGPUBuffer.getMappedRangenon-transferrable so we can detach them onGPUBuffer.unmapbut the JS spec doesn't have any way to express this at the moment.Contrary to the other TC39 topics in this issue, this one is important to figure out before WebGPU v1 as it is an important part of the WebGPU semantics (and not a future improvement).
This might also require a change to the HTML spec for structuredSerializeWithTransfer (an internal postMessage algorithm)
Reacted by Lv YitianAs mentioned above:
- Non-transferable ArrayBuffers (mapped ArrayBuffers shouldn't be transferable to other threads). (We can do this without JS changes by faking transfers, by making them actually copies instead.)
We might be able to make this work entirely within our spec instead of having to go change the behavior of ArrayBuffer. In more detail:
If you tried to transfer a getMappedRange-created ArrayBuffer, it would appear to work entirely normally - old ArrayBuffer would get detached - except the underlying data would get copied into a new, run-of-the-mill ArrayBuffer, which means that any writes to the new ArrayBuffer would not appear in the GPUBuffer upon unmap().
AFAIK, what you're describing is the behavior for non-transferable objects, though? Minus the fake detach, that is. I guess the point is that this wouldn't be an observable behavior change compared to the usual behavior (except in the context of WebGPU memory mapping, which isn't specified by TC39)?
11 remaining items
- modified the milestones: ,
on Aug 15, 2023 Any updates?
@MikhailGorobets Not at this time. This issue tracks a bunch of things, what in particular are you interested in?
@kainino0x
We are using Emscripten to compile C++ into WASM. Currently, we are facing an issue when usingWGPUDevicein a multi-threaded environment (https://emscripten.org/docs/porting/pthreads.html). For example, when creating aWGPUSamplerin a thread different from the one where theWGPUDevicewas created, we receive an invalid pointer. The problem is descripted here
Line 935 in fb97a57
Reacted by Kai NinomiyaThanks, good to know. There was some progress in investigating this direction but we have not had resources to work on it in a while. It will also of course require WebGPU to have multithreading in the first place, which is #354.
In the meantime, there's also been a little bit of investigation into Emscripten having a way to proxy all WebGPU calls to a single thread so that neither of those will be necessary. This won't perform as well, but unfortunately we haven't prototyped it yet. See emscripten-core/emscripten#19645
Please see https://github.com/tc39/proposal-immutable-arraybuffer which proposes Immutable ArrayBuffers, is at Stage 2 of the tc39 process, has enthusiastic support from some implementations, and not (yet?) any serious objections. How applicable would this be to the concerns expressed above?
@erights Thank you for letting us know about that! We are indeed interested, but right now the proposal is not compatible with WebGPU. I've filed tc39/proposal-immutable-arraybuffer#25 where we can discuss that in more depth.
- added a sub-issue
on Jun 24, 2026
mmap'ing ArrayBuffers into WASM heap.mmap), for buffer mappingAbility to make ArrayBuffers non-transferrable.It turns out this already exists as[[ArrayBufferDetachKey]]SharedObjectTablea bit likeSharedArrayBufferbut instead of containing bytes, they contain references to shallow-cloneable objects ([Serializable]IDL interface objects). This should allow for example forGPUTextures created on one worker to be instantly visible to other workers.receiveMessage()onMessagePort. (WASM multi-threading ability #476)Please add more issues on this thread.