Closed nicholasjackson closed 3 years ago
I think I might have found the answer as you detailed in this issue: https://github.com/kawamuray/wasmtime-java/issues/10#issuecomment-762309408
Now to figure how to configure as a reactor-type
Far from ideal but this does work, I will raise an issue in TinyGo to see if there is a better way round this.
tinygo build -o ../go.wasm -wasm-abi=generic -target=wasi -scheduler=coroutines -gc=leaking .
wasm2wat ../go.wasm > ../go.wat
# Remove _start line from go.wat
sed -i '/.*export "_start".*/d' ../go.wat
wat2wasm ../go.wat --output ../go.wasm
Hi, thanks for reporting the issue.
As you already figured out, a memory instance isn't ready yet at the time you try to get export because your module is recognized as a command, which creates an instance only after a function of the module is called, and destroys it before returns.
So for what you'd like to demonstrate, generating a wasm module as a reactor is right approach, but accessing memory instance is still possible with command type module as long as it happens within the callstack of the first function, such as in callback provided by host (java) side.
Here's an example, assuming your module's "main" function calls an imported function "xyz::delegate_main",
// Create a Func by yourself with low level interface, so that your handler has access to Caller, which provides getExport
Func delegateMain = new Func(store, FuncType.empty(), (caller, params, results) -> {
Memory mem = caller.getExport("memory").get().memory();
mem... // play with it
return Optional.empty();
});
linker.define("xyz", "delegate_main", Extern.fromFunc(delegateMain));
invokeMain(linker.get(store, "", "main").get().func()); // An exported memory will be touched within the callstack of this call
Great library by the way, I am giving a talk at a conference next week and I am looking forward to demoing this.
Thanks! I'm happy to hear that :)
Awesome thanks, I have another question on files but will start a different thread.
Hi,
I have been trying out the memory example and while I can get this to work with Rust and AssemblyScript compiled WASM modules I can't seem to get this working with Go code compile with WASI.
When I try to access the memory using the following code
ext
is always null from the Go Wasm module.I have compiled the module using the following flags which have worked for me when I was using the
wasmer
library.When I look at the
wat
file (attached inline), I can see the memory exported however for some reason this can not be found by wasmtime.I have also included my example code that I am using run your library. Great library by the way, I am giving a talk at a conference next week and I am looking forward to demoing this.
Example Wat: go.zip
Original Source