Scott Andrews (Oct 28 2026 at 18:37): Scott Andrews (Oct 28 2026 at 18:37):I’ve been playing around with the cooperative threads support. A sincere thank you for the heavy lifting to get this far.
Threads work, but brings along some baggage. For the 100+ components I’m currently maintaining, wasm32-unknown-unknown has been the best build target for fine grain control over imports. When I need access to a wasi capability, I import the respective interface and call it directly.
Threads support is currently gated behind wasm32-wasip3, which pulls in wasi-sdk. While it’s possible to strip out the imports wasi-sdk brings along, doing so requires no_std, and manually overriding some of the intrinsics that will be annoying to maintain. As a place to incubate thread support this is fine, but it’s not ideal in the long run. I’d like to see a way to use component model threads without wasi. I know introducing a new target is a heavy lift. How hard would it be to add threading support in wasm32-none-component?
At the risk of being reductive, component model features should exist in the component targets, and wasi features should exist in the wasi targets. Gating a component model feature to a wasi target seems like a smell.
Scott Andrews (Oct 28 2026 at 18:46):Previous discussion. #wasi > ✔ Trouble virtualizing wasi interfaces
Last updated: Oct 31 2026 at 23:03 UTC