I thought it might be useful for future WASI users to have the WASI tutorial written not only in C but also in Rust.
I'm also happy to keep the tutorial up to date with the current state of WASI target in Rust.
In more detail, this commit:
* makes fd_prestat_get safe
* rewrites fd_prestats_get_entry in (safe) Rust
* creates helper macros for rwlock read lock and unlock
If a path_open call is requesting __WASI_RIGHT_FD_FILESTAT_SET_SIZE,
interpret that as a request for write privleges. If it is requesting
O_TRUNC, require __WASI_RIGHT_PATH_FILESTAT_SET_SIZE, since this is
a path operation rather than a FD operation.
Document that `setjmp`/`longjmp` and C++ exceptions are unsupported, and
update the documentation about the function signature mismatch bug to
reflect that it's now just a warning rather than a fatal error.
* Changed `memory_grow` and `memory_index` in `Instance` struct to be `pub(crate)` and added the equivalent proxy methods to the `InstanceHandle` struct.
- Don't include an extra "*" in type of Output arguments.
- Fix the summary of environ_sizes_get.
- Put fs_rights_base and fs_rights_inherinting arguments on separate lines.
- Sort fd_prestat_dirname alphabetically before fd_prestat_get.
Currently, it's necessary to do this in order to obtain a lightbeam
checkout, in order to build wasmtime.
I'm very interested in learning about better ways to solve this problem.
For now, test all non-nightly-only packages individually, rather than
using cargo test --all. Lightbeam's tests are run separately if nightly
is available.
Avoid needlessly copying data from wasm into the host for output
parameters, and factor out the `.unwrap()` for translating pointers
when writing to output parameters.
Whether the downsides in POSIX and existing application compatibility
outweigh the benefits of thread safety remains an open question.
Right now, this note is just documenting the current behavior.
