-
Notifications
You must be signed in to change notification settings - Fork 189
feat: Add support for Swift WebAssembly compilation using SDKs that don't support pthreads #389
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
| linux_exclude_swift_versions: "[{\"swift_version\": \"5.9\"}, {\"swift_version\": \"5.10\"}]]" | ||
| windows_exclude_swift_versions: "[{\"swift_version\": \"5.9\"}]" | ||
| enable_wasm_sdk_build: true | ||
| wasm_sdk_build_command: swift build -Xcc -D_WASI_EMULATED_PTHREAD |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MaxDesiatov Just wanted to call this to your attention. With the changes in this PR, pthreads are no longer required to compile swift-async-algorithms. But I verified the pthread approach still gets compiled in when available.
Remove this build command customization seemed like the right thing to do with these changes, but interested to know your thoughts here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kateinoigakukun WDYT? IIRC import wasi_pthread is available in recent single-threaded Swift SDKs too and these conditional imports are no longer needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd say it's better to rely on the pthread stub API for better consistency with other platforms. If we don't need to support Swift 6.2, we can unconditionally import wasi_pthread regardless of p1 or p1-threads.
| import WASILibc | ||
| import wasi_pthread | ||
| #else | ||
| // No locking on WASILibc provided by the current Swift for WebAssembly SDK as of Dec 2025. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that we're using a similar approach in other swift repos
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We need to use pthread's mutex API based implementation when wasi_pthread is available.
Summary
This PR adds support for compiling
swift-async-algorithmsto wasm using the Swift SDK for WebAssembly - but without pthreads and specialized command such asswift build -Xcc -D_WASI_EMULATED_PTHREAD.This is achieved by eliding mutex locking for single-thread non-pthread WASI platforms, similar to the approach used in swift-log. This enables building
swift-async-algorithmswith the default Swift for WebAssembly configurationsThis PR is part of a larger effort by a company called PassiveLogic to enable broad support for Swift WebAssembly compilation.
Details
swift-async-algorithmswill now compile with the vanilla default configuration with these changes.Testing done
swift buildcompletes without errorsswift build --swift-sdk wasm32-unknown-wasip1 --target AsyncAlgorithmscompletes without errorsswift build --swift-sdk wasm32-unknown-wasip1-threads --target AsyncAlgorithmscompletes without errorsImpact Risk
There should be no negeative impact risk for existing targets. The changes only affect compilation for WASI platforms that don't support pthread, which was previously unsupported.