Module context

Defines the StoreContext type. Thread-local storage for storing the current store context, i.e. the currently active Store(s). When a function is called, a pointer to the StoreInner in placed inside the store context so it can be retrieved when needed. This lets code that needs access to the store get it with just the store ID.

The currently active store context can be a sync or async context.

For sync contexts, we just store a raw pointer to the StoreInner, which is owned by the embedder’s stack.

For async contexts, we store a write guard taken from the StoreAsync; This achieves two goals:

• Makes the StoreAsync available to whoever needs it, including when code needs to spawn new coroutines
• Makes sure a write lock is held on the store as long as the context is active, preventing other tasks from accessing the store concurrently.

We maintain a stack because it is technically possible to have nested Function::call invocations that use different stores, such as: call(store1, func1) -> wasm code -> imported func -> call(store2, func2)

Note that this stack is maintained by both function calls and the async_runtime to reflect the exact WASM functions running on a given thread at any moment in time. If a function suspends, its store context is cleared and later reinstalled when it resumes. This lets us use thread-local storage for the context without requiring that async tasks are tied to specific threads.

When something needs the “currently active” store context, they will only look at the top entry in the stack. It is always an error for code to try to access a store that’s “paused”, i.e. not the top entry. This should be impossible due to how the function call code is structured, but we guard against it anyway.

Structs

ForcedStoreInstallGuard 🔒

StoreAsyncGuardWrapper 🔒

StoreContext 🔒

StorePtrPauseGuard 🔒

StorePtrWrapper 🔒

Enums

GetStoreAsyncGuardResult 🔒

StoreContextEntry 🔒

StoreInstallGuard 🔒

Constants

STORE_CONTEXT_STACK 🔒