* Bring back per-thread lazy initialization Platforms Wasmtime supports may have per-thread initialization that needs to run before WebAssembly. For example Unix needs to setup a sigaltstack and macOS needs to set up mach ports. In #2757 this per-thread setup was moved out of the invocation of a wasm function, relying on the lack of Send for Store to initialize the thread at Store creation time and never worry about it later. This conflicted with [wasmtime's desired multithreading story](https://github.com/bytecodealliance/wasmtime/pull/2812) so a new [`Store::notify_switched_thread` was added](https://github.com/bytecodealliance/wasmtime/pull/2822) to explicitly indicate a Store has moved to another thread (if it unsafely did so). It turns out though that it's not always easy to determine when a `Store` moves to a new thread. For example the Go bindings for Wasmtime are generally unaware when a goroutine switches OS threads. This led to https://github.com/bytecodealliance/wasmtime-go/issues/74 where a SIGILL was left uncaught, making it appear that traps aren't working properly. This commit revisits the decision in #2757 and moves per-thread initialization back into the path of calling into WebAssembly. This is differently from before, though, where there's still only one TLS access on the path of calling into WebAssembly, unlike before where it was a separate access. This allows us to get the speed benefits of #2757 as well as the flexibility benefits of not having to explicitly move a store between threads. With this new ability this commit deletes the recently added `Store::notify_switched_thread` method since it's no longer necessary. * Fix a test compiling
This is the wasmtime-runtime crate, which contains wasm runtime library
support, supporting the wasm ABI used by wasmtime-environ,
wasmtime-jit, and wasmtime-obj.
This crate does not make a host vs. target distinction; it is meant to be compiled for the target.
Most users will want to use the main wasmtime crate instead of using this
crate directly.