support WASI

[progrium]

This issue/discussion is for adding WASI binary support for Wanix. Currently Wanix can only run binaries compiled by Go for the js runtime (not wasi, not any other language).

One initial concern was that the WASI interface is not async. In the original single-threaded Wanix prototype, this would make it impossible since our implementations of most of this interface are async. However, now that processes run in their own Web Worker, we could do async calls from there and block with a loop until we get a response. That is really the only option for native integration.

Here is an example WASI shim for running WASI directly in the browser with example implementations for most of the interfaces (but most importantly this shows what their signatures look like.. synchronous):
https://github.com/bjorn3/browser_wasi_shim/blob/main/src/wasi.ts

Another approach is to run wazero in the kernel. I've already verified simple WASI programs can be run in wazero embedded in a binary compiled for JS and run in Wanix. Wazero being implemented in Go allows it to implement "blocking" WASI functions but still yield to the Go and JS runtimes. Yes, this is WASM in WASM and will incur performance hit, but it's also probably the quickest path for at least a temporary proof of concept.

[rbbydotdev]

A couple questions for clarification please...

run in their own Web Worker, we could do async calls from there and block with a loop until we get a response.

Is the idea to run WASI binaries in web workers? - and treat them like processes?

block with a loop

A global lock?

[progrium]

Yea, we run any user executed wasm binary now in web workers as a process, so the same with WASI. Unless we run Wazero to run WASI, which would run in the kernel in that one web worker the kernel runs in. If we don't run Wazero to run WASI (which would be wasm in wasm), we'd run them in their own web workers and that would allow us to do a blocking loop. Not quite a global lock, but global to that worker, sure.