chore: For WASI builds only, use fatalError in all .wait() calls. Recommend using .get() instead.

[scottmarchant]

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]

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

[MaxDesiatov]

Does this also happen with multi-threaded Swift SDKs for WASI? If not, we should only make this conditional on multi-threading availability.

[kateinoigakukun]

It's not an SDK limitation, but the browser's limitation. They don't allow exeucting memory.atomic.wait32 instruction on the main thread regardless of the SDK variants. On multi-threading context, the opt-in busy-wait mode in wasi-libc (WebAssembly/wasi-libc#562) might make sense under some conditions, though.

[Lukasa]

Is the limitation only on the main thread? If so, we could plausibly detect specifically that condition on WASI.

[kateinoigakukun]

Correct, this is a limitation only applied to the main thread.

[Lukasa]

Ok, my recommendation then would be that we try to only diagnose this on the main thread. Can that be detected in WASI?

[scottmarchant]

Yeah, it would be really nice to be able to restrict this to just the main thread. Unfortunately from what I'm seeing I don't think that Thread.isMain compiles in Swift for WebAssembly. @MaxDesiatov are you aware of any other solutions that might work well here?

[kateinoigakukun]

Hmm, I don't think we have a good way other than recording the main thread handle in a ctor and comparing with it later.

static pthread_t main_thread;

__attribute__((constructor))
void init_main_thread() {
    main_thread = pthread_self();
}

bool is_main_thread() {
    return pthread_equal(pthread_self(), main_thread);
}

But I think we can unlock Thread.isMainThread in foundation using this approach.