Conversation
jbourassa
force-pushed
the
wasi
branch
3 times, most recently
from
08d2c65 to
f1b43b7
Compare
jbourassa
commented
Nov 24, 2022
| use wasmtime::{AsContext, AsContextMut, Store as StoreImpl, StoreContext, StoreContextMut}; | ||
| use wasmtime_wasi::{I32Exit, WasiCtx}; | ||
|
|
||
| #[derive(Debug)] |
Collaborator
Author
There was a problem hiding this comment.
Had to drop this because WasiCtx does not implement Debug.
Add APIs to support WASI: - `Linker#define_wasi` which... defines WASI for a linker. - `WasiConfig`: a builder object that holds a WASI configuration and does nothing else. The config can be changed at will -- even by mutating the underlying Ruby objects -- and and re-used across stores. - `Store#configure_wasi` to set the WASI context from `WasiConfig`. Once that's done, future changes to `WasiConfig` won't trickle to the store: the WASI state has been copied to the store. - Introduce new exception for WASI's proc_exit. This more or less follows the pattern set by the C API, except: - No "inherit env" and "inherit args". I initially had it in, but it segfaulted when reading `std::env::args()`. I don't see a lot of value in that feature, it's ambiguous (should we use ARGV which can be mutated, or the original program's args?), and can easily be replicated by sending in `ARGV` / `ENV`. - In C, it's `wasmtime_context_set_wasi(wasi_config_t)`. I chose `Store#configure_wasi` for symmetry with `Linker#define_wasi`. Also, `configure_wasi` materializes the Builder object into a WASI context, which can do file operation (opening files for stdin/out/err) -- not what I'd expect a "setter" to do. - On `Linker#instantiate`, we raise if the the store does not have a WASI context. This seems nicer than "thread '<unnamed>' panicked at..." in Ruby. I'm also not confident that catching the panic would leave the program in a good state (but probably?). ---- In a future PR, I'll introduce reading writeable streams (stdout, stderr) as Ruby strings.
jbourassa
force-pushed
the
wasi
branch
2 times, most recently
from
d4e3bb0 to
752ca63
Compare
Collaborator
Author
|
@saulecabrera I think all comments are addressed. I've made the changes as additional commits so they're easy to review. The simplest way to see the resulting API is the example or the tests. Let me know what you think! |
- `WasiConfig` is now `WasiCtxBuilder`, mapping 1:1 to Wasmtime Rust API. - `Linker#define_wasi` is now a bool kwarg on `.new`. - `Store#configure_wasi` is now a bool kwarg on `.new`.
saulecabrera
approved these changes
Nov 29, 2022
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Fixes #21.
Add APIs to support WASI:
Linker#define_wasiwhich... defines WASI for a linker.Linker.new:Linker.new(engine, wasi: true)WasiConfig: a builder object that holds a WASI configuration and does nothing else. The config can be changed at will -- even by mutating the underlying Ruby objects -- and and re-used across stores.Store#configure_wasito set the WASI context fromWasiConfig. Once that's done, future changes toWasiConfigwon't trickle to the store: the WASI state has been copied to the store.wasi_ctxkeyword argument onStore.newWasiExit: exception for WASI'sproc_exit.This more or less follows the pattern set by the C API, except:
std::env::args(). I don't see a lot of value in that feature, it's ambiguous (should we use ARGV which can be mutated, or the original program's args?), and can easily be replicated by sending inARGV/ENV.wasmtime_context_set_wasi(wasi_config_t). I choseStore#configure_wasifor symmetry withLinker#define_wasi. Also,configure_wasimaterializes the Builder object into a WASI context, which can do file operation (opening files for stdin/out/err) -- not what I'd expect a "setter" to do.Linker#instantiate, we raise if the the store does not have a WASI context. This seems nicer thanthread '<unnamed>' panicked at...in Ruby. I'm also not confident that catching the panic would leave the program in a good state (but probably?).^ Feedback / thoughts welcome on everything, but on those last 2 points in particular.
In a future PR, I'll introduce reading writeable streams (stdout, stderr) as Ruby strings.