WasmKit supports the core WASI Threads Preview 1 ABI in the CLI:
wasmkit-cli run --wasi-threads --wasi-threads-max 8 program.wasm--wasi-threads implies the core threads proposal, so --feature threads
does not need to be passed as well. The opposite does not hold: --feature threads alone only enables the core proposal and leaves wasi.thread-spawn
unlinked.
This enables the wasi.thread-spawn import with signature (i32) -> i32.
Each successful call returns a positive, monotonically increasing thread ID and
starts a fresh module instance in a fresh Store. The child calls
wasi_thread_start(i32 threadID, i32 startArgument).
The mode assumes a wasm32-wasi-threads module importing exactly one shared
wasm32 memory. The import's module/name are preserved for every instance. That
shared backing is the only mutable state shared between instances. Modules with
imported tables, mutable globals, extra memories, or other non-standard shapes
are unsupported embedder configurations.
--wasi-threads-max defaults to 64 and includes the main guest thread, so a
limit of one permits no children. IDs are allocated from 1 through
0x1FFFFFFF, are never reused, and failed attempts after reservation also
consume an ID.
This is intentionally a process-oriented CLI capability, not a general
long-lived embedding API. A worker trap or proc_exit terminates the host
process; returning from _start also terminates it, allowing the operating
system to clean up detached workers. It requires a 64-bit macOS or Linux host,
and the MultiThread package trait when building the CLI product.