Skip to content

Conversation

@scottmarchant
Copy link
Contributor

@scottmarchant scottmarchant commented Oct 22, 2025

Use fatalError in all .wait() calls for WASI builds only, and point developers towards .get() instead.

Motivation:

While working to adopt NIO in some wasm code, I've commonly ran into issues any time code calls .wait() during wasm runtime. Typically the executable either traps or crashes any time .wait() is called with an ambiguous error: Uncaught (in promise) RuntimeError: Atomics.wait cannot be called in this context. The error occurs because it is forbidden to block the main thread for a wasm executable, and the current implementation of .wait() blocks the calling thread.

The fix is straight forward, all calls to .wait() need refactor to .get(), which sometimes involves some Swift Concurrency adoption (eg. async) in the process. That change avoids blocking the main thread.

Modifications:

Added fatalError with a descriptive error message to help developers identify the issue easier.

Result:

For WASI builds only, changes the trap error message Uncaught (in promise) RuntimeError: Atomics.wait cannot be called in this context into the following error message instead:

NIO's wait() function should not be called on WASI platforms. It will freeze or crash. Use get() instead.

Alternatives considered

  • We could instead conditionalize .wait() completely out of nio for WASI builds, to turn runtime errors into compiler errors. That makes detection of this issue easier, but forces a refactor and breaking change, and somewhat precludes the possibility that WASI might support this down the road with a future change.
  • We could add a deprecation for WASI only. But long term WASI may be able to support this blocking call, so deprecation and removal is communicating the wrong message if the future ends up being reality.

Context

This PR is part of a larger effort by PassiveLogic to move Swift for WebAssembly support forward in a large number of dependencies.

@scottmarchant
Copy link
Contributor Author

@MaxDesiatov @kateinoigakukun Would love to have your thoughts on this. Open to other solutions. But from what I've experienced so far, having this change could be very helpful for developers newly adopting swift nio into their WASI builds.

@scottmarchant scottmarchant changed the title chore: Use fatalError in all .wait() calls for WASI builds only. Devs will need to use .get() instead for WASI. chore: Use fatalError in all .wait() calls for WASI builds only. Devs should use .get() instead for WASI. Oct 22, 2025
@scottmarchant scottmarchant changed the title chore: Use fatalError in all .wait() calls for WASI builds only. Devs should use .get() instead for WASI. chore: For WASI builds only, use fatalError in all .wait() calls. Use .get() instead. Oct 22, 2025
@scottmarchant scottmarchant changed the title chore: For WASI builds only, use fatalError in all .wait() calls. Use .get() instead. chore: For WASI builds only, use fatalError in all .wait() calls. Recommend using .get() instead. Oct 22, 2025
@Lukasa Lukasa added the 🔨 semver/patch No public API change. label Oct 27, 2025
@scottmarchant scottmarchant force-pushed the chore/improveErrorMessagingForWASIUsageOfNIO branch from 47b563d to af8a704 Compare October 28, 2025 00:52
@scottmarchant
Copy link
Contributor Author

Rebased these changes on the latest main

@Lukasa
Copy link
Contributor

Lukasa commented Oct 30, 2025

Arg, sorry: it looks like I lost track of that. Can you rebase again?

@scottmarchant scottmarchant force-pushed the chore/improveErrorMessagingForWASIUsageOfNIO branch from af8a704 to 8628263 Compare October 31, 2025 21:18
@scottmarchant
Copy link
Contributor Author

Arg, sorry: it looks like I lost track of that. Can you rebase again?

@Lukasa This is rebased on the latest main now.

)
#endif // os(WASI)

try self._blockingWaitForFutureCompletion(file: file, line: line)
Copy link
Member

@MaxDesiatov MaxDesiatov Nov 3, 2025

Choose a reason for hiding this comment

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

This should fix CI breakage.

Suggested change
try self._blockingWaitForFutureCompletion(file: file, line: line)
return try self._blockingWaitForFutureCompletion(file: file, line: line)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Hmm, odd that those errors don't show up for me. But could be a linux vs macOS, or swift version difference thing.

https://github.com/apple/swift-nio/actions/runs/18985478598/job/54366370185?pr=3421

But I am seeing some compiler warnings in the wasm build. I don't think adding the return will address that warning. I'll push a slightly different revision that should resolve the warnings as well.

Copy link
Member

@MaxDesiatov MaxDesiatov Nov 3, 2025

Choose a reason for hiding this comment

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

Are the errors not reproducible with the exact same invocation and container image that CI uses?

docker run -v /home/runner/work/swift-nio/swift-nio:/swift-nio -w /swift-nio \
  -e CI=true -e GITHUB_ACTIONS=true -e SWIFT_VERSION=6.0 \
  -e workspace=/swift-nio swift:6.0-jammy bash

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@MaxDesiatov I didn't see that command during my cursory glance through the build logs because it was folded inline. I opted to just build this on my own fork instead to get as close as possible to the CI in this fork.

Here is the passing build testing my latest push to verify proper a proper build failure fix: https://github.com/PassiveLogic/swift-nio/actions/runs/19044020204/job/54387663452?pr=1

But to answer your question, that command does run on my machine, but it doesn't seem to kick off any swift builds.

I found the following similar command in the build log, but it fails for me at the apt-get step.

docker run -v /home/runner/work/swift-nio/swift-nio:/swift-nio -w /swift-nio -e CI=true -e GITHUB_ACTIONS=true -e SWIFT_VERSION=6.0 -e workspace=/swift-nio swift:6.0-jammy bash -c swift --version && apt-get update -y -q && apt-get install -y -q curl jq && curl -s --retry 3 https://raw.githubusercontent.com/apple/swift-nio/main/scripts/check-cxx-interop-compatibility.sh | bash 

…existing blocking call in wait() will cause wasm executables to trap with an ambiguous message. This improves the message to help developers understand and correct the issue.
@scottmarchant scottmarchant force-pushed the chore/improveErrorMessagingForWASIUsageOfNIO branch from 8628263 to 22ae45a Compare November 3, 2025 17:20
@Lukasa Lukasa merged commit e304a1a into apple:main Nov 3, 2025
53 checks passed
@scottmarchant scottmarchant deleted the chore/improveErrorMessagingForWASIUsageOfNIO branch November 3, 2025 19:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

🔨 semver/patch No public API change.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants