wasi: provide thread-safe implementations of WASI contexts

[abrown]

With the presence of shared memories and, eventually, with wasi-threads providing a way to spawn multiple Wasm threads, access to the WASI state will no longer be single-threaded. This state (e.g., WasiCtx for wasi-common) must be appropriately protected from concurrent access, e.g., by locking as @haraldh has attempted here.

What complicates this issue is that I expect that not all users of Wasmtime will want to pay the performance penalty for locking access to WASI. This means that we may need two implementations for each WASI state object, ideally factored so that all the meaningful bits are kept in one place. Also, there may be some complications when wiring up either the single-threaded or thread-safe implementations of each WASI context during linking; presumably the thread-safe version should be used when the threads feature is enabled, but it is unclear if all of the Host types will be agreeable with this.

[alexcrichton]

One improvement that I think would be good to have is to have a method on GuestPtr<'_, str> to go to:

enum GuestCowStr<'a> {
    Borrowed(GuestStr<'a>),
    Owned(String),
 }

impl Deref for GuestCowStr<'_> {
    type Target = str;
    // ...
}

And that way all bindings in all places could create this GuestCowStr<'a> and it would work with shared and unshared memories. For unshared memories this will retain borrows and for shared memories it's required to copy bytes out no matter what and this helps encapsulate that.

Lists are harder, however, and I believe will require case-by-case handling.

[abrown]

The last time we talked about this, there were two "roadblocks" to starting to work on this issue:

1. Benchmarking: adding RwLocks (e.g.) to various fields of the WASI context structures could add some locking overhead for each WASI call. @alexcrichton hypothesized that this overhead would be minimal compared to the overhead already imposed by Wiggle. We decided to benchmark a locking implementation of wasi-common in order to decide if we can apply locking unconditionally or if we have to (undesirably) maintain two implementations of each WASI context. Now that bench: benchmark several common WASI scenarios #5274 and bench: add more WASI benchmarks #5309 are merged, we can actually measure this: use cargo bench wasi/ to run these new benchmarks first with the current HEAD and subsequently with a locking implementation. This roadblock should be gone now.
2. Async: wasi-common is designed to support both asynchronous and synchronous calls; we decided when we met that we shouldn't allow async and wasi-threads to mix. In my mind, this involved some (perhaps major) refactoring to wasi-common; @haraldh had some questions along this lines IIRC. We had discussed a separate issue to talk about what the design of this refactoring to wasi-common might look like, but now I think it could be discussed here, as a part of this issue. I would summarize this remaining roadblock as: "wasi-threads and async cannot be enabled at the same time." This has ramifications for what is allowed in the embedding API (e.g., should an async call fail with an error when the threads feature is enabled?).

[alexcrichton]

To clarify what I meant a bit about async/threads, my intention is to avoid the need for any large refactoring ideally. At a Config level we can implement a simplistic check that verifies wasm_threads and async_support are not both enabled. At the runtime layer for wiggle/wasi-common the goal would be "what's the smallest delta to support threads while not disturbing everything that's already there too much". I don't know the scale of the changes necessary, though, and I imagine that the implementation of RwLock and etc could have a large impact. In any case though I mostly wanted to outline that my reasoning is to avoid the need for refactorings unless necessary, I'm not trying to add undue work -- but at the same time recognizing that wiggle/wasi-common are used in production today and shouldn't regress from where they are.