feat: Add support for Swift WebAssembly compilation using SDKs that don't support pthreads #389
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.
@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.
@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.
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.
There was a problem hiding this comment.
@MaxDesiatov @kateinoigakukun Would it make sense to update this build command in swiftlang/github-workflows when we're able to unconditionally import wasi_pthread, and remove the customization here? That way, the build command here will remain consistent with the other wasm CI builds.
Happy to revert this, just wanted to mention that thought before reverting this line. I believe this repo will compile fine in CI either way as long as the remaining changes are in place.
There was a problem hiding this comment.
If that option doesn't belong here in this repository, but is required for import wasi_pthread to work (I haven't confirmed this myself), then IMO it should be in the Swift Driver codebase, or a Swift SDK toolset (generated by Swift SDK Generator), or somewhere on that level so that everyone gets that behavior by default.
There was a problem hiding this comment.
@MaxDesiatov +1 for enabling the emulated pthread behavior by default. I think it would help a lot more code out there compile.
There was a problem hiding this comment.
I'm leaving this as is for now. But if either of you want me to revert, please let me know. Happy to change this.
I confirmed using sdk swift-6.3-DEVELOPMENT-SNAPSHOT-2025-12-07-a_wasm that the command swift build -Xcc -D_WASI_EMULATED_PTHREAD --swift-sdk wasm32-unknown-wasip1 --target AsyncAlgorithms will make canImport(wasi_pthread) truthy, whereas swift build --swift-sdk wasm32-unknown-wasip1 --target AsyncAlgorithms makes canImport(wasi_pthread) false.
scottmarchant
force-pushed
the
feat/swift-wasm-support
branch
from
dfe9622 to
6ac957c
Compare
3 participants
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.