Skip to content

Support for Wasm using Swift SDKs that don't support pthreads#389

Merged
phausler merged 1 commit intoapple:mainfrom
PassiveLogic:feat/swift-wasm-support
Jan 12, 2026
Merged

Support for Wasm using Swift SDKs that don't support pthreads#389
phausler merged 1 commit intoapple:mainfrom
PassiveLogic:feat/swift-wasm-support

Conversation

@scottmarchant
Copy link
Copy Markdown
Contributor

@scottmarchant scottmarchant commented Dec 17, 2025

Summary

This PR adds support for compiling swift-async-algorithms to wasm using the Swift SDK for WebAssembly - but without pthreads and specialized command such as swift 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-algorithms with the default Swift for WebAssembly configurations

This PR is part of a larger effort by a company called PassiveLogic to enable broad support for Swift WebAssembly compilation.

Details

  • Added additional compilation conditionals to elide mutex locking for WASI platforms that lack pthread support and carry a decently strong guarantee of single-threaded operation.
  • Removed specialized wasm build command customization from CI configuration, since swift-async-algorithms will now compile with the vanilla default configuration with these changes.

Testing done

  • Cleaned up swiftformat lint on modified lines of change.
  • Verified unit tests still pass with these changes
  • Verified swift build completes without errors
  • Verified swift build --swift-sdk wasm32-unknown-wasip1 --target AsyncAlgorithms completes without errors
  • Verified swift build --swift-sdk wasm32-unknown-wasip1-threads --target AsyncAlgorithms completes without errors
  • Verified CI passes using CI check on separate draft PR

Impact 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.

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
Copy link
Copy Markdown
Contributor Author

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.

Copy link
Copy Markdown
Member

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?

Copy link
Copy Markdown
Contributor

@kateinoigakukun kateinoigakukun Dec 18, 2025

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.

Copy link
Copy Markdown
Contributor Author

@scottmarchant scottmarchant Dec 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

Copy link
Copy Markdown
Member

@MaxDesiatov MaxDesiatov Dec 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@MaxDesiatov +1 for enabling the emulated pthread behavior by default. I think it would help a lot more code out there compile.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 scottmarchant force-pushed the feat/swift-wasm-support branch from dfe9622 to 6ac957c Compare December 18, 2025 19:57
@MaxDesiatov MaxDesiatov changed the title feat: Add support for Swift WebAssembly compilation using SDKs that don't support pthreads feat: Add support for Wasm using Swift SDKs that don't support pthreads Dec 19, 2025
@MaxDesiatov MaxDesiatov changed the title feat: Add support for Wasm using Swift SDKs that don't support pthreads Support for Wasm using Swift SDKs that don't support pthreads Dec 19, 2025
Copy link
Copy Markdown
Member

@phausler phausler left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me

@phausler phausler merged commit d98a48b into apple:main Jan 12, 2026
22 checks passed
@phausler
Copy link
Copy Markdown
Member

@MaxDesiatov I can revert and/or land a fix.

@scottmarchant
Copy link
Copy Markdown
Contributor Author

scottmarchant commented Jan 12, 2026

@MaxDesiatov Sorry, I was following the previous swift-log pattern when I created this revision. I'll put up another PR.

@MaxDesiatov @phausler I don't think there is a need to revert this, especially since similar language and functionality has been merged to swift-log for a while now.

But agree with Max, best to update to follow the latest pattern with wasi_pthread that is currently open in PR for swift-log, for a variety of reasons.

UPDATE:

Oh, actually, it looks like the comments here are correct. It just tricked myself and @MaxDesiatov because I deviated from some import patterns used elsewhere.

The reason I think this comment is correct-ish is because the WASILibc handling is an else condition only when wasi_pthread can't be imported.

@MaxDesiatov Please feel free to confirm. I started a separate thread on one of the code patterns with more context.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants