4 ms·
WebAssembly can communicate through buffers. WebAssembly can also import foreign functions (Javascript functions in the browser). You can get output by reading
by jeroenhd 2y ago
WebAssembly can communicate through buffers. WebAssembly can also import foreign functions (Javascript functions in the browser).
You can get output by reading the buffer at the end of execution/when receiving callbacks. So, for instance, you pass a few frames worth of buffers to WASM, WASM renders pixels into the buffers, calls a callback, and the Javascript reads data from the buffer (sending it to a <canvas> or similar).
The benefit of WASM is that it can't be very malicious by itself. It requires the runtime to provide it with exported functions and callbacks to do any file I/O, network I/O, or spawning new tasks. Lua and similar tools can go deep into the runtime they exist in, altering system state and messing with system memory if they want to, while WASM can only interact with the specific API surface you provide it.
That makes WASM less powerful, but more predictable, and in my opinion better for building integrations with as there is no risk of internal APIs being accessed (that you will be blamed for if they break in an update).
- panic 2y agoI don’t believe it is currently possible for a WebAssembly instance to access any buffer other than its own memory. You have to copy data in and out.
- deathanatos 2y agoThe embedder could hand the module functions for manipulating external buffers via externrefs. (I'm not sure if that's a good idea, or not, just that it could.) But if the module wants to compute on the values in the buffer, at some level it would have to copy the data in/out.
- davexunit 2y agoUse the GC instructions and you can freely share heap references amongst other modules and the host.
- panic 2y agoHow do you access the contents of a heap reference from JavaScript in order to “send it to a <canvas> or similar”?
- davexunit 2y agoAssuming you're talking about reading binary data like (array i8), the GC MVP doesn't have a great answer right now. Have to call back into wasm to read the bytes. Something for the group to address in future proposals. Sharing between wasm modules is better right now.
- brabel 2y ago> Lua and similar tools can go deep into the runtime they exist in, altering system state and messing with system memory if they want to That's not correct, when you embed Lua you can choose which APIs are available, to make the full stdlib available you must explicitly call `luaL_openlibs` [1]. [1] https://www.lua.org/manual/5.3/manual.html#luaL_openlibs https://www.lua.org/manual/5.3/manual.html#luaL_openlibs
- westurner 2y agoWASI Preview 1 and WASI Preview 2 can do file and network I/O IIUC. Re: tty support in container2wasm and fixed 80x25 due to lack of SIGWINCH support in WASI Preview 1: https://github.com/ktock/container2wasm/issues/146 https://github.com/ktock/container2wasm/issues/146 The File System Access API requires granting each app access to each folder. jupyterlab-filesystem-access only works with Chromium based browsers, because FF doesn't support the File System Access API: https://github.com/jupyterlab-contrib/jupyterlab-filesystem-access https://github.com/jupyterlab-contrib/jupyterlab-filesystem-... The File System Access API is useful for opening a local .ipynb and .csv with JupyterLite, which builds CPython for WASM as Pyodide. There is a "Direct Sockets API in Chrome 131" but not in FF; so WebRTC and WebSocket relaying is unnecessary for WASM apps like WebVM: https://news.ycombinator.com/item?id=42029188 https://news.ycombinator.com/item?id=42029188
- westurner 2y agoWASI Preview 2: https://github.com/WebAssembly/WASI/blob/main/wasip2/README.md https://github.com/WebAssembly/WASI/blob/main/wasip2/README.... : > wasi-io, wasi-clocks, wasi-random, wasi-filesystem, wasi-sockets, wasi-cli, wasi-http