Support per-task TLS in wasip3 - #872
Merged
Merged
Conversation
dicej
approved these changes
Aug 19, 2026
| // If this is a multi-module program then `main_tls` is actually an array base | ||
| // pointers for each library. Swap that with the old main thread's values in | ||
| // `saved_ptr`. | ||
| void **ret = saved_ptr; |
Collaborator
There was a problem hiding this comment.
I'll never get used to how C silently, implicitly converts from void* to any pointer type.
This commit is another update to how TLS is handled on the WASIp3 target
in wasi-libc. The problem being addressed here is that bindings
generators (aka `wit-bindgen`) currently use context slot 0 as
task-local storage but this is being co-opted for the stack pointer (and
slot 1 is the TLS base) on WASIp3 targets. This means that bindings
generators don't actually have anywhere to put task-local information
and the previous scheme of implicit threads always using the main thread
TLS meant that there was no way to distinguish anything.
To resolve this the `__wasm_task_hook`, which already exists, now
manages TLS-per-task. This is implemented to work with the full matrix
of {single,multi-module} x {coop-threads,no-coop-threads} through some
refactoring and such. Effectively TLS is dynamically allocated at task
startup and then deallocated when a task completes. Some hooks, like
resource destructors, `_initialize`, post-return, etc, all run with the
"main thread" TLS as before. Tasks can now, on WASIp3 targets, use
normal TLS storage to store task-local data.
alexcrichton
force-pushed
the
per-task-tls
branch
from
August 19, 2026 17:37
98731e3 to
d8620a8
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This commit is another update to how TLS is handled on the WASIp3 target
in wasi-libc. The problem being addressed here is that bindings
generators (aka
wit-bindgen) currently use context slot 0 astask-local storage but this is being co-opted for the stack pointer (and
slot 1 is the TLS base) on WASIp3 targets. This means that bindings
generators don't actually have anywhere to put task-local information
and the previous scheme of implicit threads always using the main thread
TLS meant that there was no way to distinguish anything.
To resolve this the
__wasm_task_hook, which already exists, nowmanages TLS-per-task. This is implemented to work with the full matrix
of {single,multi-module} x {coop-threads,no-coop-threads} through some
refactoring and such. Effectively TLS is dynamically allocated at task
startup and then deallocated when a task completes. Some hooks, like
resource destructors,
_initialize, post-return, etc, all run with the"main thread" TLS as before. Tasks can now, on WASIp3 targets, use
normal TLS storage to store task-local data.