Describe a primitive reactor ABI. #256
Conversation
This adds a new reactor ABI, indicated by exporting the function "_activate". For now, a reactor is just a module which doesn't have a lifetime scoped by a "_start" or "main" function, though it may evolve to include other semantics in the future.
|
I should also mention, a lot of people are already effectively using reactor-style modules in practice. This change just allows us to support this use case properly, as it allows the C++ and libc runtimes to initialize themselves. |
This adds support for the WASI reactor ABI proposed in WebAssembly/WASI#256, as well as the existing _start ABI for commands. This also implements the semantics that command instances should not persist after their _start function is called. As a safety measure, this includes a check that the instance refcount is 1, so that other references to the instance don't hold it live. Implementing that prompted a change to how the main Instance API works. Instead having instances eagerly compute a Vec of Externs, and bumping the refcount for each Extern, compute Externs on demand. This also means that the closure returned by `get0` and friends now holds an `InstanceHandle` to dynamically hold the instance live rather than being scoped to a lifetime.
|
|
||
| - `_start` - the program entry point | ||
| - `memory` - linear memory used by the program | ||
| - A *command* exports a function named `_start`, with no arguments and no return |
There was a problem hiding this comment.
Partially off topic, but why not pass some configuration data to _start?
For example, the function could receive the command line args, the allowed paths, etc. These would be through interface types, of course.
There was a problem hiding this comment.
Yes, exactly. There are a lot of things we could do here, but we need interface types to do them well. The current argv/environ interfaces we have now aren't super amazing, and _start isn't a great name, and so on, but at the moment it all works well enough that it doesn't seem worth breaking compatibility until we have a big reason for it, like interface types.
|
As I mentioned in this comment, this ABI is expected to change in the future, so this won't be the final word here, but it is simple solution to a present problem, so let's move forward. |
This adds a new reactor ABI, indicated by exporting the function
"_activate". For now, a reactor is just a module which doesn't have
a lifetime scoped by a "_start" or "main" function, though it may
evolve to include other semantics in the future.