Repository navigation
Importing a Wasm program #30
Description
This came up in the nodejs PR (nodejs/node#27850), there are some concerns about import a WebAssembly Module that is a program.
We might want to:
- only import some exported symboles and avoiding calling the main function.
- calling the main function in a safe way; seperated memory, forked from the main process.
We don't provide any solution for this, apart from transforming the module AOT because it's part of the spec semantics.
Activity
xtuc commentedon Jun 6, 2019
Thinking about this more, @guybedford I think that already in JavaScript a library can spawn an interface on top of your app, with not much control.
If we want control over the process the JavaScript module syntax might not be suited. Which is similar to js.
I believe it's more a toolchain convention issue because they could explicitly export main function and import/export the memory.
guybedford commentedon Jun 6, 2019
The current directions seem to be to have WASI modules export the memory and have the "main" run on import, but my concern is that while this makes complete sense as a technical model, we need to ensure that this model is well-suited to how toolchains can be expected to be used and integrated with the ES module system.
I understand that toolchains are still somewhat in flux here too, but then we shouldn't rush the runtime semantics likewise.
tschneidereit commentedon Jun 6, 2019
That'll certainly not be the case in the long run: exporting the memory by default is a clear break of encapsulation that a module would need to explicitly opt in to. Whether the main function is run or not will also differ between modules—this touches on the Commands and Reactors patterns @sunfishcode described and recently provided an experimental implementation of.
guybedford commentedon Jun 6, 2019
@tschneidereit thanks so much for those links. Having runtimes being able to distinguish memory handling as well as Command or Reactor WASI modules, and handling the initialization appropriately sounds very sensible.
My primary concern here though is whether or not the ESM integration of WASM for a Command should run the "main" on import, as I don't want us to be in a position where a lot of useful WASI code written as Command / programs requires custom Node.js processes or VM initializations to run together within a larger application.
devsnek commentedon Jun 13, 2019
given that i can import a source text assumed to be an entry point (e.g. something like
import 'bin/run.mjs'), why would we make an exception for wasi? additionally in a runtime using esm, it would be odd to have an exception where processing the entry point is sometimes not done via the esm loader. (mytool file.mjsvsmytool file.wasmwherefile.wasmis a wasi command)guybedford commentedon Aug 11, 2019
Node.js has set up a fork for WASI development in https://github.com/nodejs/wasi/.
This fork is open to collaboration and PRs, which may be a useful incubator for ESM integration proposals related to WASI, providing a path for allowing experimentation that can move to upstreaming into Node.js core under experimental flags and finally as stable.
guybedford commentedon Jul 11, 2025
This problem has since been solved by the source phase imports proopsal. In addition in the WebAssembly instance integration, we now have
wasm:andwasm-js:schemes reserved on imports and exports so can in theory add additional contracts in future to smooth integration. The recommendation remains to use source phase imports though for these kinds of cases.