bytecodealliance
Support a WASI reactor target
Operating system: macOS Processor architecture: M1 (arm64) Rust version: not applicable Javy version: latest
Problem
WASI/WASM ceremony is all over the place depending on what compiler produced the module. Most expect _start or _initialize to be called prior to any exported functions being invoked.
In the case of modules produced by Javy, if _start is called any subsequent calls to exported functions will fail with wasmtime reporting they’re unreachable.
If I remove my calls to _start then I can call into my exported functions without issue.
Javy-generated modules, are WASI-compliant by default. More concretely, Javy-generated modules are Commands, which according to the WASI specification:
A Command has a "main" function, and when this function returns the program terminates.
The main function referenced in the specification is the exported _start function; in that sense, calling any other function after calling _start will result in a panic. In theory we could make Javy modules be configurable (either a Command or Reactor) if that's something that you need for your use-case.
Right, I figured that was the case. The reason for my issue is because if we look at say TinyGo's WASM/WASI target, it requires you to call _start before calling any other methods and in reality behaves like a reactor even though it is a command module (they're currently working on a reactor compile target.)
Why this is relevant is my use-case loads extensions written in any programming language which are compiled to a WASI module, and we have to workaround and support the various calling conventions and ceremony each compiler requires since everyone is fast and loose with the standards.
So, with that being said, a reactor target would be great for Javy so we can have setup code and still call exported functions.
If you're willing to work on a PR to add this functionality, I'd be happy to review it.