You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In line with how EXE formats work, it would be useful if we could declare a custom section that is exposed as a read-only memory section to a webassembly module. The runtime could then memory-map the WASM file contents into an address space accessible by webassembly to efficiently represent the data.
Because this would store arbitrary binary data, the contents of the read-only memory store could be anything, including some sort of tiny zipfile format to recreate an entire miniature read-only filesystem within the WASM module. An example syntax would be using file://foo to refer to file foo in the embedded zipfile.
It would technically be possible to make this memory write-able or even extensible, but this might be a bad idea, because it then state is being stored inside the .wasm file, which breaks statelessness assumptions and basically everything else.
Under the hood, this feature is dependent on multiple memories, and would likely be related to standard optimizations looking for read-only memories that would be declared inside the EXE itself when compiled.
The text was updated successfully, but these errors were encountered:
In line with how EXE formats work, it would be useful if we could declare a custom section that is exposed as a read-only memory section to a webassembly module. The runtime could then memory-map the WASM file contents into an address space accessible by webassembly to efficiently represent the data.
Because this would store arbitrary binary data, the contents of the read-only memory store could be anything, including some sort of tiny zipfile format to recreate an entire miniature read-only filesystem within the WASM module. An example syntax would be using
file://foo
to refer to filefoo
in the embedded zipfile.It would technically be possible to make this memory write-able or even extensible, but this might be a bad idea, because it then state is being stored inside the .wasm file, which breaks statelessness assumptions and basically everything else.
Under the hood, this feature is dependent on multiple memories, and would likely be related to standard optimizations looking for read-only memories that would be declared inside the EXE itself when compiled.
The text was updated successfully, but these errors were encountered: