Hi Bruno,
Thank you for taking a look at this.
> - How do _you_ compile and run a program in this environment?
> The same way as in [2], or do you do it differently?
Yes, I use wasi-sdk[1] as described in the document. My current motivation is porting
libidn to WebAssembly and I needed to apply this patch to make it work.
To be precise, I use the following configuration to cross-build libidn with this Gnulib patch.
```
$ ../libidn/configure --host wasm32-wasi --enable-cross-guesses=risky --disable-doc \
CFLAGS='-D_WASI_EMULATED_PROCESS_CLOCKS -fPIC' LDFLAGS='-lwasi-emulated-process-clocks' \
RANLIB=$WASI_SDK_PATH/bin/llvm-ranlib AR=$WASI_SDK_PATH/bin/llvm-ar CC=$WASI_SDK_PATH/bin/clang
```
> - [1] promises that the programs "may run anywhere—from browsers to clouds
> to embedded devices". How do you run such a program in a browser?
> How do you run it in the "cloud"? How do you run it on a memory-
> restricted computer?
First of all, WebAssembly is a specification of a set of virtual instruction set and program format.
It's quite similar to JVM, but it's enough low-level to be able to lower LLVM IR to the program format.
Recent major browsers have implemented execution engines for WebAssembly alongside their _javascript_ engines.
Those engines typically validate the given program and translate the virtual instruction sequence into native one _or_
just interpret it. The program effectively has isolated memory space from the host environment and also needs to have
explicit verifiable metadata to interact with the host system[2]. Therefore, browsers can run such programs without certain
class of security issues.
The spec of WebAssembly does not mention the existence of "browser" at all, and its runtime can be implemented
outside of browsers. One of the major implementations of such standalone runtime is wasmtime[3], and also there is a
smaller runtime implementation for restricted environments[4].
WASI is an interface specification between host system and guest program and we have a libc implementation on the top of
it based on musl[4].
The current major limitations on the WASI and WebAssembly stack are:
1. Control flow is restricted to be _structured_, so setjmp/longjmp cannot be implemented easily.
(We have a way based on CPS transformation but it's quite expensive)
2. WASI still defines quite a small space of interfaces compared with POSIX system calls for now.
It has a basic file system, environment variable, socket, etc..., but still doesn't have something corresponding to getrlimit or
flock, or something like that.
Given that our libc implementation is based on musl and it's already supported in this project, I think the work required to port
Gnulib to WASI/WebAssembly would be basically providing stub implementations for functions that cannot be implemented yet
due to a lack of the system interface spec.
Let me know if you need more information :)
Thanks,
Yuta