45ff2fe12f
This prepares for exposing operations like Memory.Grow while keeping the ability to trace what did that, by adding a `context.Context` initial parameter. This adds this to all API methods that mutate or return mutated data. Before, we made a change to trace functions and general lifecycle commands, but we missed this part. Ex. We track functions, but can't track what closed the module, changed memory or a mutable constant. Changing to do this now is not only more consistent, but helps us optimize at least the interpreter to help users identify otherwise opaque code that can cause harm. This is critical before we add more functions that can cause harm, such as Memory.Grow. Signed-off-by: Adrian Cole <adrian@tetrate.io>
Allocation examples
The examples in this directory deal with memory allocation concerns in WebAssembly, e.g. How to pass strings in and out of WebAssembly functions.
$ go run greet.go wazero
wasm >> Hello, wazero!
go >> Hello, wazero!
While the below examples use strings, they are written in a way that would work for binary serialization.
- Rust - Calls Wasm built with
cargo build --release --target wasm32-unknown-unknown - TinyGo - Calls Wasm built with
tinygo build -o X.wasm -scheduler=none --no-debug -target=wasi X.go
Note: Each of the above languages differ in both terms of exports and runtime behavior around allocation, because there is no WebAssembly specification for it. For example, TinyGo exports allocation functions while Rust does not. Also, Rust eagerly collects memory before returning from a Wasm function while TinyGo does not.
We still try to keep the examples as close to the same as possible, and highlight things to be aware of in the respective source and README files.