porting of programs between Wasmer and Cowasm

[martin12333]

I wonder, how easy or difficult will it be to port programs

• from Wasmer to Cowasm
• from Cowasm to Wasmer

// I plan to study and do experiments, EDIT: first plan:
https://github.com/sagemathinc/cowasm/blob/main/Dockerfile https://github.com/sagemathinc/cowasm#build-from-source

EDIT:
related:

• Compatibility with Emscriptenforge, Pyodide, Pyscript? #43

[williamstein]

Hi @martin12333 , the way the CoWasm.sh runs subprocesses in the browser is implemented here:

https://github.com/sagemathinc/cowasm/blob/main/packages/kernel/src/wasm/worker/posix-context.ts#L159

It's basically an implementation of "fork + exec" but entirely within a single WASM instance, which is I think simple, flexible and fast, but of course has drawbacks. The way it works is:

1. Make a copy of all state -- memory, WASI, etc.
2. Load the program to run as a dynamic library -- for this to work, the program needs to be built -fPIC, which most WebAssembly programs aren't.
3. Runs the main (or similar) function in the dynamic library
4. After termination of the program, restores state from the copy.
5. Also keep track of unloading dll's from memory.

When running under node.js there's also a different fork/exec implementation, but it's less accurate. There's also an implementation that works very well for Python. (These are for running native subprocesses, and I care about this mainly so I can use pip to install and building C compiled Python packages from source...)

The steps above are just one neat way of efficiently running programs without the complexity of multiple WebAssembly instances, which leverages this packages https://www.npmjs.com/package/dylink that I wrote. It has drawbacks, of course. cowasm could also be extended to run programs in other ways.

Thanks for noticing CoWasm!