Add application-abi describing the current unstable WASI application ABI #48
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,32 @@ | ||
| WASI Application ABI | ||
| ==================== | ||
|
|
||
| In addition to the APIs defined by the various WASI [modules](modules.md) there | ||
| are also certain expectations that the WASI runtime places on an application | ||
| that wishes to be portable across WASI implementations. | ||
|
|
||
| This document describes how a conforming WASI application is expected to behave | ||
| in terms of lifecycle (startup, shutdown, etc) and imports and exports the that | ||
| it is expected to include. | ||
|
|
||
| Lifecycle | ||
| --------- | ||
|
|
||
| A WASI program may contain any number exports, but the embedded attributes | ||
| specific meaning the following optional function exports: | ||
|
|
||
| - `__wasi_init` - Called after WebAssemembly instantiation but before any other | ||
| functions. | ||
| - `__wasi_main` - Runs the programs main entry points. May be omitted, for | ||
| example, in the case of a library. | ||
| - `__wasi_term` - The logical inverse of `__wasi_init`. Optionally called | ||
| before module destruction. No other functions within program will be called | ||
| after this one. | ||
sbc100 marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| Linear Memory | ||
| ------------- | ||
|
|
||
| All WASI programs are expected to share a linear memory with the embedder. The | ||
| memory can either be imported from the embedder or exports to the embedder. If | ||
| exported the memory must be named `__wasi_memory`. If imported the import must | ||
|
There was a problem hiding this comment. do we need to have the ability to both import and export memory? What would be the usecase for importing memory that isn't covered just by exporting? There was a problem hiding this comment. I was actually surprised to see that the wasi toolchain currently exports memory by default. I suppose that is because wasm-ld happens to have that is its default. As a point of reference emscripten module import their memory from the embedder by default. If we want to support sharing of memories the importing is the only way to go. If every module creates and exports it own memory there is no way they can access the same one. I suppose we could start by documenting the status quo which is to export the memory from the module, and then extend this later as needed? There was a problem hiding this comment. It was also a conscious decision to have modules define their own memories -- looking forward to wasm modules compiled from languages which don't use linear memories, or which use multiple linear memories, it seems like it will be awkward for the host to try to provide exports for the things applications will need. The Command/Reactor/Library ontology can help here as well -- Commands and Reactors would (typically) define the main memory, and Libraries would (typically) import it. |
||
| be named `memory` from a module names `wasi`. | ||
|
There was a problem hiding this comment. For now, the module should be Also, while we're renaming things, can we rename "memory" to "__wasi_memory" too? |
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It'd be good to mention how the wasm start function fits into this lifecycle as well.