pyodide-webassembly-runtime-layer
implements the wasm_runtime_layer
backend API to provide access to the web browser’s WebAssembly
runtime
using Pyodide
.
The implementation of this crate is heavily inspired by the web_backend
of the wasm_runtime_layer
. Instead of relying on the js-sys
and
wasm-bindgen
crates to generate JavaScript-based bindings to the
WebAssembly
JavaScript API, this crate uses Pyodide
’s js
FFI
layer to interact with WebAssembly
through Python running inside
WASM. pyodide-webassembly-runtime-layer
is therefore useful when
developing a Python module in Rust, e.g. using PyO3
, which requires
access to some WASM runtime using the wasm_runtime_layer
API and
may be deployed to the web itself using Pyodide
.
pyodide-webassembly-runtime-layer
generally tries to keep memory
management intuitive by relying primarily on Python’s reference counting to
drop objects once they are no longer needed by both the user-written Rust
code and the WebAssembly
runtime. As this crate coordinates interop
across Rust, Python, and JavaScript, it takes extra care to avoid reference
cycles across the different memory management strategies of the languages
which would otherwise lead to memory leakage. If using this crate produces a
memory leak that is avoided with a different wasm_runtime_layer
backend,
please report it as a bug.
There is one exception to the intuitive memory management strategy:
Func::new
creates a host function, which may capture arbitrary data.
To avoid cross-language reference cycles, it is stored using wobbly
references inside the Func
and its associated Store
. Even though
the host function and its data are dropped once either the Store
is
dropped or references to the Func
are dropped, additional bookkeeping
data is required until both have been dropped.WebAssembly
web runtime.Instance
or a host
function.Module
.Engine
, which stores host-defined data T
and internal
state.