SYSTEM Cited by 3 sources

WebAssembly

WebAssembly (Wasm) is a portable binary-instruction format designed as a compile target for languages like C, C++, Rust, Zig, Go, and others — embedded inside web browsers, runtimes like Node.js and Deno, and serverless platforms like Cloudflare Workers via the V8 engine (and via workerd in Cloudflare's case).

Role on this wiki

Canonical system for Rust-on-Wasm reliability (Cloudflare's 2026-04-22 post) and for the Wasm Exception Handling proposal's production relevance. The post covers:

• Compile targets — the wasm32-unknown-unknown Rust target (panic=abort by default; panic=unwind newly supported via Cloudflare's wasm-bindgen work).
• Sandbox model — each Wasm instance is a sandbox with linear memory, imported/exported functions, and no ambient authority; the Rust↔JS boundary is a real trust boundary. When the instance is corrupted, any request served by it can produce undefined behaviour (sandbox-poisoning).
• Exception handling — historically Wasm had no unwinding; panics and C++ exceptions terminated the instance. The WebAssembly Exception Handling proposal fixes this with try / catch / throw instructions, gaining wide engine support in 2023. "Legacy exception handling" (initial) vs "modern exception handling with exnref" (final) are the two variants; Rust Wasm targets still default to legacy.
• Stack unwinding on Wasm — with Exception Handling, catch_all blocks run destructors and rethrow propagates — enabling native-Rust stack-unwinding semantics on Wasm.

Engine support for modern EH (as of 2026-04-22 post)

Runtime	Version	Released
V8	13.8.1	2025-04-28
workerd	v1.20250620.0	2025-06-19
Chrome	138	2025-06-28
Firefox	131	2024-10-01
Safari	18.4	2025-03-31
Node.js	25.0.0	2025-10-15

Node.js 24 LTS was the constraint — its release schedule would have left the ecosystem on legacy EH until April 2028 without action. Cloudflare backported modern EH to Node.js 24 and 22 so modern EH can become the default target "next year."

Seen in

• sources/2026-04-22-cloudflare-making-rust-workers-reliable-panic-and-abort-recovery-in-wasm-bindgen — canonical wiki instance. Deep dive on the Wasm instance as a unit of failure (sandbox poisoning), the EH proposal as the primitive enabling Rust panic recovery on Wasm, and Cloudflare's Node.js 22/24 backport to keep wasm-bindgen's default target viable.

Related

• systems/wasm-bindgen — the Rust↔JS binding generator exercising Wasm EH in the Rust ecosystem.
• systems/workers-rs — Rust SDK targeting Wasm.
• systems/cloudflare-workers — Wasm runtime at edge scale.
• systems/workerd — open-source Wasm runtime behind Workers.
• systems/v8-javascript-engine / systems/nodejs — major Wasm EH consumers.
• webassembly-exception-handling — the proposal.
• panic-unwind / panic-abort — the Rust-panic-strategy axis that rides on Wasm EH.
• sandbox-poisoning — the failure class EH + abort recovery now contains.
• stack-unwinding — the runtime primitive Wasm EH enables on this substrate.
• concepts/capability-based-sandbox — adjacent sandbox discipline at the instance tier.

Wasm as the language-portability substrate for serverless (2026-09-21)

Wasm's role as a compile target for non-JS languages inside a serverless runtime is exactly what let Cloudflare ship Python Workers GA: rather than run native CPython, Cloudflare compiles the Pyodide Python interpreter to Wasm and runs it in the same Workers runtime as JavaScript. Two Wasm-sandbox realities shaped the implementation:

• No ambient OS networking. POSIX socket syscalls inside a Wasm sandbox are stubs that fail, so TCP database drivers can't open connections. Cloudflare implemented socket syscalls at the syscall level on top of the Workers connect() API, so unmodified Python drivers work (enabling Hyperdrive).
• Cross-compilation of native extensions. Any package with native C/C++/Rust extensions must be cross-compiled to Wasm; Cloudflare drove PEP 783 / PyEmscripten — built on Emscripten — to standardize this across the whole Python-on-Wasm community.

(Source: sources/2026-09-21-cloudflare-python-workers-are-now-generally-available)

JSPI: JavaScript Promise Integration for blocking-as-park (2026-09-28)

JavaScript Promise Integration (JSPI) is the WebAssembly proposal that lets a blocking Wasm call suspend the WebAssembly stack on a synchronous operation and return control to the JS event loop — then resume when a Promise settles. This maps "directly onto Tokio's existing parking semantics": a suspend is exactly a thread park, so a Rust async runtime built around parking can run on a single-threaded JS host if blocking is expressed as a JSPI suspend.

The proposal also supports stack switching under suspension — a new Wasm stack can be entered while an earlier one is suspended. That capability is what makes it usable for concurrency, but it is also the source of the subtle failure mode Cloudflare had to solve for Tokio: a JSPI stack switch is not a thread switch, so Rust's thread-local state (Tokio's runtime context) is shared across the suspended and newly-entered stacks. Supporting fully reentrant JSPI therefore requires swapping the thread-local context on each JSPI enter/exit/suspend/resume — "cooperative time-multiplexed threading, with each suspended stack carrying its own runtime context." See systems/tokio for the full treatment.

(Source: sources/2026-09-28-cloudflare-supporting-native-rust-in-workers-with-the-new-emscripten-target)

Seen in (additional)

• sources/2026-09-28-cloudflare-supporting-native-rust-in-workers-with-the-new-emscripten-target — JSPI as one of the two mechanisms (alongside Tokio's LocalEventLoop) that let a parking-based Rust runtime run inside the single-threaded Workers JS event loop, via the Emscripten wasm32-unknown-emscripten target.