177af53578
* Remove the unused EnsureDarwinMachPorts function When compiling the C++ shims for longjmp/setjmp/signal handling we don't use the `USE_APPLE_MACH_PORTS` directive, so this function was entirely unused anyway. This looks to be a holdover from when this was originally copied from C++, but no need for keeping around this now-legacy initialization. * Remove the `wasmtime_init_finish` function This looks like it's perhaps largely historical cruft at this point now I think? The function, with the removal of the mach ports from the previous commit, only reads the initializtion state of the signal handlers. If the signal handlers failed to get installed, though, it simply returns early rather than erroring out anyway. In any case a follow-up commit will refactor `wasmtime_init_eager` to handle this as well. * Pare down `wasmtime_init_eager` Similar to previous commits it looks like this function may have accrued some debt over time, nowadays it doesn't really do much other than capture a backtrace and install signal handlers. The `lazy_static` state isn't really that necessary and we can rely on the `Once` primitive in the standard library for one-time initialization. This also updates the code to unconditionally panic if signal handlers fail to get installed, which I think is the behavior that we'll want for now and we can enhance it over time if necessary, but I don't think we have a use case where it's currently necessary.
Wasmtime: a WebAssembly Runtime
A Bytecode Alliance project
Wasmtime is a standalone wasm-only optimizing runtime for WebAssembly and WASI. It runs WebAssembly code outside of the Web, and can be used both as a command-line utility or as a library embedded in a larger application.
To get started, visit wasmtime.dev.
There are Rust, C, and C++ toolchains that can compile programs with WASI. See the WASI intro for more information, and the WASI tutorial for a tutorial on compiling and running programs using WASI and wasmtime, as well as an overview of the filesystem sandboxing system.
Wasmtime passes the WebAssembly spec testsuite. To run it, update the
tests/spec_testsuite submodule with git submodule update --remote, and it
will be run as part of cargo test.
Wasmtime does not yet implement Spectre mitigations, however this is a subject of ongoing research.
Additional goals for Wasmtime include:
- Support a variety of host APIs (not just WASI), with fast calling sequences, and develop proposals for additional API modules to be part of WASI.
- Facilitate development and testing around the Cranelift and Lightbeam JITs, and other WebAssembly execution strategies.
- Develop a native ABI used for compiling WebAssembly suitable for use in both JIT and AOT to native object files.
Including Wasmtime in your project
Wasmtime exposes an API for embedding as a library through the wasmtime subcrate,
which contains both a high-level and safe Rust API, as well as a C-compatible API
compatible with the proposed WebAssembly C API.
For more information, see the Rust API embedding chapter of the Wasmtime documentation.
It's Wasmtime.