- Introduced the virtual BUS interface used for RPC between web assembly apps
- Introduced the virtual networking interface used to implement networking
for web assembly apps
- Implemented a local implementation of the virtual networking
(available behind the feature toggle 'host-net' on the 'wasi' package)
- Fixed up some of the examples from the wasmer3 branch
- Refactored the WASI implementations so they support wasm64-wasi
- WASIX is behind its own namespaces for both 32bit and 64bit implementations
- Fixed the wasi_pipes unit test which was using internals that are no longer exposed - instead made the pipes clonable
- Split functionality out of WasiEnv so that it can support multi-threading
- Added methods to the VFS File Trait that supporting polling
- Implemented basic time functionality for WASI
- Incorported a yield callback for when WASI processes idle
- Improved the error handling on WASI IO calls
- Reduce the verbose logging on some critical WASI calls (write/read)
- Implemented the missing poll functionality for WASI processes
- Moved the syspoll functionality behind a feature flag to default to WASI method
- Refactored the thread sleeping functionality for WASI processes
- Fixed the files system benchmark which was not compiling
- Modified the file system trait so that it is SYNC and thus can handle multiple threads
- Removed the large mutex around filesystem state and implemented granular locks instead
(this is needed to fix a deadlock scenario on the terminal)
- Split the inodes object apart from the state to fix the deadlock scenario.
- Few minor fixes to some warnings when not using certain features
- Sleeping will now call a callback that can be used by the runtime operator when
a WASI thread goes to sleep (for instance to do other work)
- Fixed a bug where paths that exist on the real file system are leaking into VFS
- Timing functions now properly return a time precision on WASI
- Some improved macros for error handling within syscalls (wasi_try_ok!)
- Refactored the remove_directory WASI function which was not working properly
- Refactored the unlink WASI function which was not working properly
- Refactored the poll WASI function which was not working properly
- Updates some of the tests to make them compile again
- Rewrote the OutputCapturer so that it does leak into the internals
`JsValue.as_string` converts the value to String iff the value is a
String itself, so the error message always failovers to empty string.
`JsValue` impls `Debug` using `JSON.stringify`, and it gives better
description of the error.
2807: Run Wasm code on a separate stack r=Amanieu a=Amanieu
This uses the [corosensei](https://crates.io/crates/corosensei) crate to
run Wasm code on a separate stack from the main thread stack.
In trap handlers for stack overflows and memory out of bounds accesses,
we can now check whether we are executing on the Wasm stack and reset
execution back to the main thread stack when returning from the trap
handler.
When Wasm code needs to perform an operation which may modify internal
data structures (e.g. growing a memory) then execution must switch back
to the main thread stack using on_host_stack. This is necessary to avoid
leaving internal data structure in an inconsistent state when a stack
overflow happens.
In the future, this can also be used to suspend execution of a Wasm
module (#1127) by modeling it as an async function call.
Fixes#2757Fixes#2562
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
This uses the [corosensei](https://crates.io/crates/corosensei) crate to
run Wasm code on a separate stack from the main thread stack.
In trap handlers for stack overflows and memory out of bounds accesses,
we can now check whether we are executing on the Wasm stack and reset
execution back to the main thread stack when returning from the trap
handler.
When Wasm code needs to perform an operation which may modify internal
data structures (e.g. growing a memory) then execution must switch back
to the main thread stack using on_host_stack. This is necessary to avoid
leaving internal data structure in an inconsistent state when a stack
overflow happens.
In the future, this can also be used to suspend execution of a Wasm
module (#1127) by modeling it as an async function call.
Fixes#2757Fixes#2562
The field ordering here is actually significant because of the drop
order: we want to drop the artifact before dropping the engine.
The reason for this is that dropping the Artifact will de-register the
trap handling metadata from the global registry. This must be done before
the code memory for the artifact is freed (which happens when the store
is dropped) since there is a chance that this memory could be reused by
another module which will try to register its own trap information.
Note that in Rust, the drop order for struct fields is from top to
bottom: the opposite of C++.
In the future, this code should be refactored to properly describe the
ownership of the code and its metadata.
Fixes#2434
2728: Replace RuntimeError::raise with RuntimeError::custom r=syrusakbary a=Amanieu
`RuntimeError::raise` should not be exposed to user code since it perfoms a `longjmp` internally which is unsound if there are any destructors on the stack. Instead a custom error type should be returned using `RuntimeError::custom` which can be passed through WASM code and later retrieved using `RuntimeError::downcast`.
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
