Run TLS destructors for wasm32-wasip1-threads make Node.js stuck

[Brooooooklyn]

I tried this code:

https://github.com/Brooooooklyn/rust-wasi-thread-local-stuck

use std::cell::RefCell;
use std::collections::HashMap;

thread_local! {
  static THREAD_LOCAL_DATA: RefCell<HashMap<u32, u32>> = RefCell::new(HashMap::new());
}

#[unsafe(no_mangle)]
pub unsafe extern "C" fn set_thread_local_data(key: u32, value: u32) {
    THREAD_LOCAL_DATA.with(|data| {
        data.borrow_mut().insert(key, value);
    });
}

I expected to see this happen: Program run and exit normally

Instead, this happened: hang forever

(edit): See toyobayashi/emnapi#136 (comment) for where and why

Meta

rustc --version --verbose:

rustc 1.85.0 (4d91de4e4 2025-02-17)
binary: rustc
commit-hash: 4d91de4e48198da2e33413efdcd9cd2cc0c46688
commit-date: 2025-02-17
host: aarch64-apple-darwin
release: 1.85.0
LLVM version: 19.1.7

Background

The NAPI-RS project enables the compilation of Rust projects to the wasm32-wasip1-threads target, allowing them to run in Node.js. However, since Node.js doesn’t natively support WASI threads, we simulate a threaded environment using emnapi. This setup worked effectively until version 1.85.0. Many projects, such as rolldown and rspack, have been successfully compiled to WebAssembly targets to run seamlessly on platforms like StackBlitz and in web browsers.

[Noratrieb]

When users compile to wasm32-wasip1-threads, they don't necessarily enable target_feature = "atomics", but the rust-std of wasm32-wasip1-threads always enables atomics, which causes some issues: #137510.

#133472 (comment)

The wasm32-wasip1-threads target enables the atomics feature by default, so it's always used (unless someone unsoundly turns it off).

rust/compiler/rustc_target/src/spec/targets/wasm32_wasip1_threads.rs

Line 62 in e0be1a0

options.features = "+atomics,+bulk-memory,+mutable-globals".into();

[Brooooooklyn]

The wasm32-wasip1-threads target enables the atomics feature by default, so it's always used (unless someone unsoundly turns it off).

I misunderstood, there should be other reasons for this. In the Node.js context, I suspect it's because libc::pthread_key_delete calls an Atomics.wait API, causing the JavaScript code to hang on the main thread.

[surban]

Could you reproduce this without node.js, i.e. minimal example running on wasmtime?

[Brooooooklyn]

Could you reproduce this without node.js, i.e. minimal example running on wasmtime?

@surban it works fine on wasmtime, I think this might be an issue specific to Node.js/Browser

[surban]

Could you reproduce this without node.js, i.e. minimal example running on wasmtime?

@surban it works fine on wasmtime, I think this might be an issue specific to Node.js/Browser

I don't know how exactly emnapi is emulating threads, but since this works fine with native threads on wasmtime, I suspect the issue is with emnapi and not Rust.

[Brooooooklyn]

I don't know how exactly emnapi is emulating threads, but since this works fine with native threads on wasmtime, I suspect the issue is with emnapi and not Rust.

The logic stuck before going into emnapi, there is no emnapi and NAPI-RS in my repro: https://github.com/Brooooooklyn/rust-wasi-thread-local-stuck

use std::cell::RefCell;
use std::collections::HashMap;

thread_local! {
  static THREAD_LOCAL_DATA: RefCell<HashMap<u32, u32>> = RefCell::new(HashMap::new());
}

#[unsafe(no_mangle)]
pub unsafe extern "C" fn set_thread_local_data(key: u32, value: u32) {
    THREAD_LOCAL_DATA.with(|data| {
        data.borrow_mut().insert(key, value);
    });
}

import { WASI } from 'node:wasi'
import fs from 'node:fs'
const wasi = new WASI({
  version: 'preview1',
  env: process.env,
})

const wasm = await WebAssembly.compile(
  new Uint8Array(fs.readFileSync('target/wasm32-wasip1-threads/debug/wasi_thread_local.wasm')),
)

const instance = await WebAssembly.instantiate(wasm, {
  ...wasi.getImportObject(),
  env: {
    memory: new WebAssembly.Memory({ initial: 1024, maximum: 65536, shared: true }),
  },
})

wasi.initialize(instance);

console.log(instance.exports.set_thread_local_data(1, 2))