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
js_wasm_runtime_layer
backend for 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.