Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 0 additions & 1 deletion .github/workflows/pull_request.yml
Original file line number Diff line number Diff line change
Expand Up @@ -15,7 +15,6 @@ jobs:
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.

Copy link
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
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
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
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.


soundness:
name: Soundness
Expand Down
13 changes: 13 additions & 0 deletions Sources/AsyncAlgorithms/Locking.swift
Original file line number Diff line number Diff line change
Expand Up @@ -21,6 +21,9 @@ import WinSDK
import Bionic
#elseif canImport(wasi_pthread)
import wasi_pthread
#elseif canImport(WASILibc)
// No locking on WASILibc provided by the current Swift for WebAssembly SDK as of Dec 2025.
// That SDK is also single-threaded, so we can safely avoid locking altogether.
#else
#error("Unsupported platform")
#endif
Expand All @@ -30,6 +33,8 @@ internal struct Lock {
typealias Primitive = os_unfair_lock
#elseif canImport(Glibc) || canImport(Musl) || canImport(Bionic) || canImport(wasi_pthread)
typealias Primitive = pthread_mutex_t
#elseif canImport(WASILibc)
// This WASILibc variation is single threaded, provides no locks
#elseif canImport(WinSDK)
typealias Primitive = SRWLOCK
#else
Expand All @@ -49,6 +54,8 @@ internal struct Lock {
#elseif canImport(Glibc) || canImport(Musl) || canImport(Bionic) || canImport(wasi_pthread)
let result = pthread_mutex_init(platformLock, nil)
precondition(result == 0, "pthread_mutex_init failed")
#elseif canImport(WASILibc)
// This WASILibc variation is single threaded, provides no locks
#elseif canImport(WinSDK)
InitializeSRWLock(platformLock)
#else
Expand All @@ -69,6 +76,9 @@ internal struct Lock {
os_unfair_lock_lock(platformLock)
#elseif canImport(Glibc) || canImport(Musl) || canImport(Bionic) || canImport(wasi_pthread)
pthread_mutex_lock(platformLock)
#elseif canImport(WASILibc)
// This WASILibc variation is single threaded, provides no locks
return
#elseif canImport(WinSDK)
AcquireSRWLockExclusive(platformLock)
#else
Expand All @@ -82,6 +92,9 @@ internal struct Lock {
#elseif canImport(Glibc) || canImport(Musl) || canImport(Bionic) || canImport(wasi_pthread)
let result = pthread_mutex_unlock(platformLock)
precondition(result == 0, "pthread_mutex_unlock failed")
#elseif canImport(WASILibc)
// This WASILibc variation is single threaded, provides no locks
return
#elseif canImport(WinSDK)
ReleaseSRWLockExclusive(platformLock)
#else
Expand Down