Host Functions

[ubiquitous-dev]

What is your question?

How can I call a host (imported) function from within a javascript application compiled with javy?

Details

First of all, great work on Javy! It's really awesome what ya'll are building.

Pulling out the quickjs runtime into a separate dynamic module is a great idea. It's a lot of overhead to ship an entire interpreter or runtime with every wasm program when it's going to be the same code every time (other than the user's code).

One thing I'm not clear on with Javy is how to call host (imported) functions. I believe calling code outside of the WASM module is already being done via the dynamic linker, but it seems to be calling wasm <=> wasm, rather than from wasm => host.

For example, if I am running wasmtime embedded within a Go application - how can I have the javascript code running inside the quickjs runtime (with or without dynamic linking) invoke a Go method and get the response back into the javascript execution environment?

I believe WASI is implemented basically the same as host functions, but the signature of WASI is known ahead-of-time, so I'm guessing that WASI's structure is hardcoded into the javy compiler, as are the function signatures used for the runtime linking. Is that right, and if so, is there a way to build the code so that it relies on an import that doesn't exist during compile time, but only during execution time?

Thanks in advance, and great work on Javy!

[jeffcharles]

How can I call a host (imported) function from within a javascript application compiled with javy?

The short answer is you currently can't without forking Javy or using the quickjs-wasm-rs crate directly unfortunately. We are exploring options for how to make Javy more extensible so this will be feasible in the future.

The longer answer is, in the core crate (or in whatever crate you have consuming quickjs-wasm-rs), given an existing quickjs-wasm-rs Context, you can invoke wrap_callback and provide a Rust function that returns a closure matching the signature required by wrap_callback, and that Rust function can invoke an imported function. My understanding is you can use an extern block and the link_name attribute on the function you're importing to make the imported function available to the Rust function you define. This should work for both static and dynamic linking. In the dynamic case, the bytecode is evaluated in the provider module, i.e., the one with the interpreter in it, so that module is the one invoking the imported function.

Hopefully that was helpful!

[ubiquitous-dev]

Thanks for the additional context! So if I understand correctly:

quickjs-wasm-rs is a rust module that wraps the quickjs runtime. Javy's core is basically a rust application that implements quicks-wasm-rs to execute javascript code, and it also wraps up some WASI bindings to inject into the quickjs instance so it appears to quickjs that those methods exist (but when they're called, they're running the native Rust code). The thing that's being built into wasm is the Javy core application (a rust app with an embedded quickjs interpreter and some bindings so quickjs can invoke rust code which will then call WASI on its behalf). So if I wanted to expose more imported functions, I would just need to implement them in Javy's core application and wrap them and expose them to the quickjs interpreter? And the reason that this isn't something that's generically available is because there would need to be a mechanism to register these additional imported functions somehow and inject their definitions into the quickjs runtime and proxy between quickjs and core?

[jeffcharles]

quickjs-wasm-rs is a rust module that wraps the quickjs runtime.

Broadly speaking yes. It's a Rust crate that contains a number of modules and the aim of the crate is to provide a more ergonomic API around quickjs-wasm-sys which directly bind to the QuickJS C library.

Javy's core is basically a rust application that implements quicks-wasm-rs to execute javascript code, and it also wraps up some WASI bindings to inject into the quickjs instance so it appears to quickjs that those methods exist (but when they're called, they're running the native Rust code).

Broadly yes. The quickjs-wasm-* crates are also compiled to a WASI target so they can also invoke WASI calls. The core crate wires up some functionality that makes WASI calls and makes it available in the JS context.

The thing that's being built into wasm is the Javy core application (a rust app with an embedded quickjs interpreter and some bindings so quickjs can invoke rust code which will then call WASI on its behalf).

Yes!

So if I wanted to expose more imported functions, I would just need to implement them in Javy's core application and wrap them and expose them to the quickjs interpreter?

Yes. wrap_callback on Context does both wrapping and exposing. You can look at globals.rs in the core crate to see how we do that. We probably won't accept a PR into this repo that adds new functions unless they're applicable across a range of applications so you would need to maintain a fork in that case.

And the reason that this isn't something that's generically available is because there would need to be a mechanism to register these additional imported functions somehow and inject their definitions into the quickjs runtime and proxy between quickjs and core?

Broadly speaking yes. The other big issue is function implementations being injected may only be applicable in one or a small number of environments. For example, if someone wants to add a fetch implementation, there isn't a standardized hostcall available to make HTTP calls or to open a socket, and we wouldn't want to add a requirement to provide a proprietary hostcall for network calls because that would mean Javy modules could not be instantiated in as wide a variety of runtimes as is the case today. The presence of the Rust code containing the hostcall is sufficient to add the requirement to provide that hostcall implementation whether or not the JS actually invokes that hostcall. We are investigating options to make this easier.