Skip to content

Conversation

@TartanLlama
Copy link
Contributor

@TartanLlama TartanLlama commented Dec 4, 2025

Threads are currently not created on sync->sync export calls, sync host->guest calls, and module-level start function calls. This PR adds support to this for all of these.

I added a component-model-async feature to wasmtime-environ so that sync->sync adapters are compiled as they were originally for wasip2 code, avoiding changing performance characteristics.

Rather than use the existing prepare_call + start_call machinery, I introduced sync_to_sync_enter/exit_call intrinsics to avoid adding additional host frames to the stack for sync calls.

Currently, doing operations that require thread state inside post_return functions is unsupported. If we're happy merging this as-is and creating an issue to resolve this later, we can do so, or I can try and address it prior to merging.

Fixes #11954

@github-actions github-actions bot added the wasmtime:api Related to the API of the `wasmtime` crate itself label Dec 4, 2025
@github-project-automation github-project-automation bot moved this to Backlog in Ship WASIp3 Dec 4, 2025
@alexcrichton alexcrichton moved this from Backlog to In progress in Ship WASIp3 Dec 8, 2025
@TartanLlama TartanLlama marked this pull request as ready for review December 11, 2025 15:05
@TartanLlama TartanLlama requested review from a team as code owners December 11, 2025 15:05
@TartanLlama TartanLlama requested review from abrown and removed request for a team December 11, 2025 15:05
@TartanLlama TartanLlama requested review from pchickey and removed request for a team December 11, 2025 15:05
@fitzgen fitzgen added the wasm-proposal:component-threading Issues related to cooperative threading in the component model label Dec 18, 2025
@dicej dicej requested review from alexcrichton and dicej and removed request for abrown and pchickey January 7, 2026 17:24
@dicej
Copy link
Contributor

dicej commented Jan 7, 2026

I've only skimmed this so far; it looks generally reasonable, but I expect it will conflict with #12153, which I'm about to split into smaller PRs per @alexcrichton's request.

Given that the component-model-async feature is now enabled by default, we'll need to be conscious of the overhead of e.g. calling sync_to_sync_enter_call and sync_to_sync_exit_call per this Zulip topic. In #12153, I had to get creative and sometimes lazily push GuestTasks and GuestThreads as necessary to avoid pessimizing sync-to-sync adapters. @TartanLlama we should chat sometime about if (and if so, how) we could do a similar optimization here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

wasm-proposal:component-threading Issues related to cooperative threading in the component model wasmtime:api Related to the API of the `wasmtime` crate itself

Projects

Status: In progress

Development

Successfully merging this pull request may close these issues.

resources.wast test failing in sync mode with cooperative multithreading

3 participants