Alex Crichton 70345aff31 Remove all global state from the caching system (#863)
* Remove all global state from the caching system

This commit is a continuation of an effort to remove usages of
`lazy_static!` and similar global state macros which can otherwise be
accomodated with passing objects around. Previously there was a global
cache system initialized per-process, but it was initialized in a bit of
a roundabout way and wasn't actually reachable from the `wasmtime` crate
itself. The changes here remove all global state, refactor many of the
internals in the cache system, and makes configuration possible through
the `wasmtime` crate.

Specifically some changes here are:

* Usage of `lazy_static!` and many `static` items in the cache module
  have all been removed.
* Global `cache_config()`, `worker()`, and `init()` functions have all
  been removed. Instead a `CacheConfig` is a "root object" which
  internally owns its worker and passing around the `CacheConfig` is
  required for cache usage.
* The `wasmtime::Config` structure has grown options to load and parse
  cache files at runtime. Currently only loading files is supported,
  although we can likely eventually support programmatically configuring
  APIs as well.
* Usage of the `spin` crate has been removed and the dependency is removed.
* The internal `errors` field of `CacheConfig` is removed, instead
  changing all relevant methods to return a `Result<()>` instead of
  storing errors internally.
* Tests have all been updated with the new interfaces and APIs.

Functionally no real change is intended here. Usage of the `wasmtime`
CLI, for example, should still enable the cache by default.

* Fix lightbeam compilation
2020-02-06 13:11:06 -06:00
2020-02-05 14:14:07 -06:00
2019-12-13 17:29:36 +01:00
2019-11-08 17:15:19 -08:00
2019-11-08 17:22:37 -06:00
2019-11-13 14:10:30 +01:00

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.

build-status gitter-chat-badge minimum-rustc

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.

Description
No description provided
Readme 125 MiB
Languages
Rust 77.8%
WebAssembly 20.6%
C 1.3%