wapc / wapc-rust Goto Github PK

Hi!

Similar to grpcurl for grpc, a small utility that offers a way to invoke a wapc call via the command line would be useful for debugging and development... I'm imagining something like

wapcurl [-e engine] [-d payload] <wasm file> <function>

I wouldn't be surprised if this existed already, so I figured I'd ask. 🙂

Wasmtime 0.15.0 has one large breaking change, the removal of the Callable trait. Now, it works more like what wasmer did with the Context, where the signature of the function you pass to Func::new() takes a Caller struct, which allows you to access the exports of the instance.

The main issue I see is that right now each of the Callable objects that we've got is storing a reference to the instance (this is now superfluous), but it's also storing the module state, which has all of the "current values" for the guest request, response, error, etc that facilitate the waPC protocol.

Those values will likely have to be moved into a hashmap stored in a lazy_static to keep the values/call state isolated between modules. What's even more difficult is that without module state being bound to individual callbacks, we need to figure out another way to uniquely identify/number the wasm modules so they can be distinguished both for individual call state and for consuming libraries (like wascc)

hello, i want to use this crate in openwrt. but it does not exists AtomicU64 in mipsel-unknown-linux-musl. can i push a pr to change to AtomicU32 so that it can support mipsel-unknown-linux-musl?

After going down the rabbit hole of providing an optional callback that can be used by consuming libraries to provide their own logging capabilities, it seems more obvious now that the console_log function is at the wrong abstraction level.

The waPC standard provides for the minimal set of WebAssembly calls required to facilitate bi-directional function calls. It definitely violates that abstraction to have the ability for the guest to make a direct console_log function.

If a guest module needs to request that its host perform a logging operation, then that should be a first-class waPC function call from the guest to the host, where the operation, namespace, and payload are something that both the host and guest understand. For example, this might be an operation called LogWrite in the namespace wascc:logging with a payload containing the debug log level, the text of the log output, and potentially other metadata.

CC'ing @pkedy for potential discussion on this issue as removal of that call from the Rust host has implications that it should be removed from the standard and therefore not supported by any host runtime.

Add a conditional feature wasm3 to the project that, when active, will compile the crate using the wasm3 interpreter instead of the wasmtime JIT/compiler. This would allow people to build code on top of wapc that could optimize for running either in full (wasmtime) environments or embedded/limited (wasm3) environments.

wasmtime 0.8.0 and 0.9.0 are incompatible and there are breaking changes. Upgrade to wasmtime 0.9.0.

Per Issue 5 in wapc-guest-rust, both guest and host sides need to be aware of and support the binding field in the __host_call function.

Hi. I'm further diving into wapc, and there're some very nice ideas in there! 😃

One thing I could not find so far is, are you able to stop a guest call of it's taking too much time? In wasmtime, you'd use the interrupt handle to set a trap, but I don't see why of that used here. What's your approach? 🤔

If possible, enable a feature flag that allows the waPC host to compile/run without access to std. This will facilitate it being used as a foundation for higher-level functionality that can be available on embedded / limited devices.

Related to #4 , where wasm3 might be a potential option. other alternatives include using wasmi.

Right now the waPC standard exposes a single function that allows an actor to emit log text. The current naive implementation in Rust is to simply dump that information to STDOUT. This prevents higher-level projects written using waPC (like waSCC) from being able to provide their own, more robust logging implementation.

Right now we're not allowing the use of WASI modules but that is a limitation that no longer exists in wasmtime. Now that we've upgraded to the latest version of wasmtime, we should be able to add the WASI imports to the regular waPC host imports.

Current version of waPC utilizes wasmer, wasmer-runtime, and wasmer-wasi for its webassembly interpreting and JIT compiling. See if it's possible to port this underlying support to the bytecode alliance's wasmtime library.

NOTES - It looks like function calling is pretty straightforward and should be easily translatable. The one embedding sample I've seen doesn't show how to construct the externs you pass to the module instance, nor does it show you how to manipulate module memory from a guest invocation, so those feel like the biggest unknowns.

Ideally I'd also like to know how well wasmtime performs when making simple invocations.
The main things we need to be able to continue to do in the wasmtime implementation:

• Uniquely identify module instances (using a monotonically increasing number right now)
• Support both "pure isolated" and WASI loading