Wasmtime GitHub notifications bot (Jan 26 2023 at 19:45): Wasmtime GitHub notifications bot (Jan 26 2023 at 19:45):bjorn3 commented on issue #152:
I think this can be closed now as the polyfill at https://wasi.dev/polyfill/index.html is gone.
Wasmtime GitHub notifications bot (Jan 26 2023 at 20:41):jameysharp closed issue #152:
The current polyfill, if I understand correctly, is an emscripten-compiled program that contains a wasi runtime implemented in POSIX. Emscripten's POSIX support is then used to run the wasi. And the polyfill program contains all the code necessary to run the entire wasi API, so that it can run an arbitrary wasi program.
@dschuff and I were thinking about the following use case: an existing wasi executable exists, and someone wants to package it for the web. Using the current polyfill would work, but it's larger than it needs to be for most programs. In theory it would be nice if we could do
emcc -Os wasi_program.wasm -o wasi_program.htmland get html+js+wasm that works and is as small as possible - that is, if emscripten could take wasi programs as input, link in necessary stuff, emit an optimized and minified JS runtime, etc. However it seems like that can't quite work, because wasi executables are not relocatable - and so we can't link in the wasm parts of the emscripten runtime.Alternatively, if a relocatable wasi was provided, that could work. However, if we're not using a plain wasi executable anymore, then we can maybe just recompile the program from source using emscripten anyhow - that is, the recommended path for people would be to make sure their programs compile with both the wasi and emscripten sdks, if they want to both run on the server and also run on the web with minimal size. But this has downsides. Maybe there's a better option?
Another possible thought here - what if wasi executables were relocatable?
Last updated: Dec 23 2024 at 13:07 UTC