Public-facing futex API#834
Merged
Merged
Conversation
TartanLlama
marked this pull request as draft
July 17, 2026 16:21
| hidden int __wasilibc_pthread_mutex_unlock(pthread_mutex_t *m, int yield); | ||
| #else | ||
| hidden int __wasilibc_futex_wait(volatile void *, int, int, int64_t); | ||
| hidden int __wasilibc_futex_wait_syscall(volatile void *, int, int, int64_t); |
Collaborator
There was a problem hiding this comment.
Could callers directly call __wasilibc_futex_wait to avoid the need for this extra symbol?
Collaborator
Author
There was a problem hiding this comment.
This is a lower-level function that is meant to replace the raw syscall invocation, so it's an implementation detail of the public __wasilibc_futex_wait
TartanLlama
marked this pull request as ready for review
July 20, 2026 16:25
alexcrichton
approved these changes
Jul 20, 2026
jhpratt
added a commit
to jhpratt/rust
that referenced
this pull request
Jul 24, 2026
…onthey std: Implement futex on wasip3 targets, update target spec This commit is in preparation for eventual [tier 2 status] for the `wasm32-wasip3` target. Initially this target will not have support for threads but it's expected to come ~later this year. The first step in supporting this is switching internal `#[cfg]` in the standard library to "ok this target has threads", and this commit is the update for synchronization primitives. All synchronization primitives on the `wasm32-wasip3` now use a `futex`-based implementation, and the implementation of the futex itself is located in wasi-libc (see WebAssembly/wasi-libc#834). Other WASI targets can eventually all use this implementation as well, but `wasi-libc`'s implementation of these symbols will need to percolate, so those targets aren't changed yet. For `wasm32-wasip3`, however, any supporting `wasi-libc` will have these symbols. This then additionally fixes the target to actually build with a modern LLVM by passing a necessary flag to `wasm-ld`. This flag isn't supported until LLVM 23, but the `wasm32-wasip3` target isn't fully supported until LLVM 23 anyway (hence its Tier 3 status currently). [tier 2 status]: rust-lang/compiler-team#1001
rust-timer
added a commit
to rust-lang/rust
that referenced
this pull request
Jul 24, 2026
Rollup merge of #159731 - alexcrichton:wasip3-futex, r=clarfonthey std: Implement futex on wasip3 targets, update target spec This commit is in preparation for eventual [tier 2 status] for the `wasm32-wasip3` target. Initially this target will not have support for threads but it's expected to come ~later this year. The first step in supporting this is switching internal `#[cfg]` in the standard library to "ok this target has threads", and this commit is the update for synchronization primitives. All synchronization primitives on the `wasm32-wasip3` now use a `futex`-based implementation, and the implementation of the futex itself is located in wasi-libc (see WebAssembly/wasi-libc#834). Other WASI targets can eventually all use this implementation as well, but `wasi-libc`'s implementation of these symbols will need to percolate, so those targets aren't changed yet. For `wasm32-wasip3`, however, any supporting `wasi-libc` will have these symbols. This then additionally fixes the target to actually build with a modern LLVM by passing a necessary flag to `wasm-ld`. This flag isn't supported until LLVM 23, but the `wasm32-wasip3` target isn't fully supported until LLVM 23 anyway (hence its Tier 3 status currently). [tier 2 status]: rust-lang/compiler-team#1001
github-actions Bot
pushed a commit
to rust-lang/rustc-dev-guide
that referenced
this pull request
Jul 25, 2026
std: Implement futex on wasip3 targets, update target spec This commit is in preparation for eventual [tier 2 status] for the `wasm32-wasip3` target. Initially this target will not have support for threads but it's expected to come ~later this year. The first step in supporting this is switching internal `#[cfg]` in the standard library to "ok this target has threads", and this commit is the update for synchronization primitives. All synchronization primitives on the `wasm32-wasip3` now use a `futex`-based implementation, and the implementation of the futex itself is located in wasi-libc (see WebAssembly/wasi-libc#834). Other WASI targets can eventually all use this implementation as well, but `wasi-libc`'s implementation of these symbols will need to percolate, so those targets aren't changed yet. For `wasm32-wasip3`, however, any supporting `wasi-libc` will have these symbols. This then additionally fixes the target to actually build with a modern LLVM by passing a necessary flag to `wasm-ld`. This flag isn't supported until LLVM 23, but the `wasm32-wasip3` target isn't fully supported until LLVM 23 anyway (hence its Tier 3 status currently). [tier 2 status]: rust-lang/compiler-team#1001
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.
Adds
__wasilibc_futex_{wait,wake}functions that can be used by external code to use futexes across cooperative or wasi-threads builds. The functions trap in single-threaded builds.We could have separate
__wasilibc_futex_waitand__wasilibc_futex_timed_waitfunctions if we want a simpler API for clients that don't need the timed behaviour. I don't have particularly strong feelings either way.