Wasmtime GitHub notifications bot (Mar 30 2025 at 15:27): Wasmtime GitHub notifications bot (Mar 30 2025 at 15:27):PPakalns opened issue #10491:
Feature
Support adding SharedMemory defines to ?Linker? for use in components in Component Model.
Benefit
Wasm on web supports threaded execution. Wasmtime supports threaded execution. WIT (Component model) simplifies host - guest interface definition a lot.
It would be very useful to add some kind of (experimental) support for threaded execution in Component model. Threaded execution requires SharedMemory.
Use case
This would allow to execute Wasm component in multi-threaded program. For example in multi threaded game engines the same Wasm component can be called from multiple threads to process/generate data.
Related discussion and collection of blog posts:
#general > Calling Wasm logic from multiple threads with shared memoryImplementation
Allow to define shared memory imports in wasmtime::component::Linker?
Component linker defines:
https://docs.wasmtime.dev/api/src/wasmtime/runtime/component/linker.rs.html#103Wasmtime main linker defines:
https://docs.wasmtime.dev/api/src/wasmtime/runtime/linker.rs.html#119Maybe this can be added as experimental feature under feature flag.
Alternatives
Avoid using WIT and try to reimplement the same functionality using wasmtime without Component Model.
Wasmtime GitHub notifications bot (Mar 30 2025 at 15:28):PPakalns edited issue #10491:
Feature
Support SharedMemory for use in component in Component Model (WIT).
Benefit
Wasm on web supports threaded execution. Wasmtime supports threaded execution. WIT (Component model) simplifies host - guest interface definition a lot.
It would be very useful to add some kind of (experimental) support for threaded execution in Component model. Threaded execution requires SharedMemory.
Use case
This would allow to execute Wasm component in multi-threaded program. For example in multi threaded game engines the same Wasm component can be called from multiple threads to process/generate data.
Related discussion and collection of blog posts:
#general > Calling Wasm logic from multiple threads with shared memoryImplementation
Allow to define shared memory imports in wasmtime::component::Linker?
Component linker defines:
https://docs.wasmtime.dev/api/src/wasmtime/runtime/component/linker.rs.html#103Wasmtime main linker defines:
https://docs.wasmtime.dev/api/src/wasmtime/runtime/linker.rs.html#119Maybe this can be added as experimental feature under feature flag.
Alternatives
Avoid using WIT and try to reimplement the same functionality using wasmtime without Component Model.
Wasmtime GitHub notifications bot (Mar 30 2025 at 15:39):PPakalns commented on issue #10491:
Sadly I don't know in detail how Component model is implemented.
Would like to call wasm component from multiple threads. And with WIT (Component model) Wasm is very easy to integrate in projects.
I hope that there aren't major problems of using Shared Memory inside Wasm Instance in Component model context.
Thank you for this great project, looking forward to how wasmtime will improve in future.
Wasmtime GitHub notifications bot (Mar 30 2025 at 15:55):bjorn3 commented on issue #10491:
Threading support for the component model will use the shared-everything threads proposal, which Wasmtime doesn't support yet. As opposed to the instance-per-thread pattern as commonly used in the browser that requires importing shared memories.
Wasmtime GitHub notifications bot (Mar 30 2025 at 17:23):PPakalns commented on issue #10491:
Related issue: https://github.com/bytecodealliance/wasmtime/issues/9466
Wasmtime GitHub notifications bot (Mar 30 2025 at 17:23):PPakalns edited a comment on issue #10491:
Related shared-everything-threads issue: https://github.com/bytecodealliance/wasmtime/issues/9466
Wasmtime GitHub notifications bot (Mar 31 2025 at 10:49):PPakalns commented on issue #10491:
Maybe someone with knowledge can answer if there are major problems with "highly experimental temporary" approach until shared-everything-threads is implemented.
Theoretically, If I fork wasmtime and I modify wasmtime so that SharedMemory is passed to Instance (and I initialize multiple Instances with the same shared memory and correctly initialize stack/TLS for each instance), is there obvious problems why it might not work and would conflict with Component model.
Wasmtime GitHub notifications bot (Mar 31 2025 at 10:50):PPakalns edited a comment on issue #10491:
Maybe someone with knowledge can answer if there are major problems with "highly experimental temporary" approach until shared-everything-threads is implemented.
Theoretically, If I fork wasmtime and I modify wasmtime so that SharedMemory is passed to Instance (and I initialize multiple Instances with the same shared memory and correctly initialize stack/TLS for each instance), is there obvious problems why it might not work and would conflict with Component model.
Thank you for your help.
Wasmtime GitHub notifications bot (Mar 31 2025 at 18:37):alexcrichton closed issue #10491:
Feature
Support SharedMemory for use in component in Component Model (WIT).
Benefit
Wasm on web supports threaded execution. Wasmtime supports threaded execution. WIT (Component model) simplifies host - guest interface definition a lot.
It would be very useful to add some kind of (experimental) support for threaded execution in Component model. Threaded execution requires SharedMemory.
Use case
This would allow to execute Wasm component in multi-threaded program. For example in multi threaded game engines the same Wasm component can be called from multiple threads to process/generate data.
Related discussion and collection of blog posts:
#general > Calling Wasm logic from multiple threads with shared memoryImplementation
Allow to define shared memory imports in wasmtime::component::Linker?
Component linker defines:
https://docs.wasmtime.dev/api/src/wasmtime/runtime/component/linker.rs.html#103Wasmtime main linker defines:
https://docs.wasmtime.dev/api/src/wasmtime/runtime/linker.rs.html#119Maybe this can be added as experimental feature under feature flag.
Alternatives
Avoid using WIT and try to reimplement the same functionality using wasmtime without Component Model.
Wasmtime GitHub notifications bot (Mar 31 2025 at 18:37):alexcrichton commented on issue #10491:
I'm going to close this in favor of https://github.com/bytecodealliance/wasmtime/issues/9466 as that's the tracking issue for now of implementing that proposal. @abrown has been working on this for now, but no demos are ready as of now of everything working end-to-end.
Threads + components is, at this time, a pretty broad topic that spans everything from standards to implementation to toolchains to conventions and such. It's not really in a state of "oh just hack this up here and you can see it all working". Even just understanding why it's not possible to easily tack on threads requires background knowledge of components/wasm/etc. Basically I do not have the time/energy to type up what I feel will be a satisfactory answer to your questions here, and all I can leave you with is that components + threads does not work at this time. You're welcome to check back in in the future, but for now there is no feasible short path to getting this working.
Wasmtime GitHub notifications bot (Mar 31 2025 at 19:03):PPakalns commented on issue #10491:
Thank you for your explanation :) Looking forward to shared-everything-threads proposal.
Last updated: Apr 17 2025 at 04:04 UTC