mirror of
https://github.com/hanzoai/wasm.git
synced 2026-10-30 15:07:30 +00:00
zeekayandHanzo Dev
5d9fcc1ed3
A wrapper over wazero, not a fork. wazero is pure Go with no cgo, so a binary embedding it cross-compiles like any other and carries no runtime to install beside it — which is why wasm belongs in the process rather than in a container. What this adds is the part every caller otherwise gets wrong the same three ways. Compile once and instantiate per call, because those are different costs (~833 µs against ~249 µs on one module) and only one of them is per-request. Bound a guest by default, because the zero value is what most callers ship and an unset bound must not mean an unlimited one. And instantiate anonymously, because many live sandboxes of one module is the ordinary case and it should not require inventing unique names. The measurements say why this is not a container: 89 ns warm, 249 µs for a fresh sandbox, against 37.5 ms for a pooled container and 228 ms to spawn a wasm CLI. A module is already a sandbox — it reaches no memory it was not given and holds no syscalls unless a host hands them over — so a container around one buys a second boundary the first already provides. It is deliberately not a home for everything. WASI has no process spawn, so a guest cannot run git, pytest, pip or cargo; that absence is what makes the sandbox cheap, and work needing a kernel runs under Visor instead. Co-authored-by: Hanzo Dev <[email protected]>
5 lines
332 B
Plaintext
5 lines
332 B
Plaintext
github.com/tetratelabs/wazero v1.11.0 h1:+gKemEuKCTevU4d7ZTzlsvgd1uaToIDtlQlmNbwqYhA=
|
|
github.com/tetratelabs/wazero v1.11.0/go.mod h1:eV28rsN8Q+xwjogd7f4/Pp4xFxO7uOGbLcD/LzB1wiU=
|
|
golang.org/x/sys v0.38.0 h1:3yZWxaJjBmCWXqhN1qh02AkOnCQ1poK6oF+a7xWL6Gc=
|
|
golang.org/x/sys v0.38.0/go.mod h1:OgkHotnGiDImocRcuBABYBEXf8A9a87e/uXjp9XT3ks=
|