Skip to content

Conversation

@scottmarchant
Copy link

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

import WASILibc
import wasi_pthread
#else
// No locking on WASILibc provided by the current Swift for WebAssembly SDK as of Dec 2025.
Copy link
Author

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

Copy link
Contributor

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.

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.

3 participants