Share wasm instance by several threads about wasm-c-api HOT 5 OPEN

Yes, it's possible, but not without changes to this API.

WAVM supports this by splitting the WASM store into "compartments" and "contexts". Contexts correspond to thread-local state, and compartments to shared state. Modules are instanced in compartments instead of contexts, and so may be used from any context in the compartment.

The way you get WASM thread-local variables in browsers is by instantiating a module once for each thread: in WAVM you only instantiate a module once in the compartment, and it is equivalent to instantiating the module in each context with the same arguments.

When you instantiate a module in WAVM, it must do a little bit of work for each context in the compartment, and when you create a context, it must do a little bit of work for each instance in the compartment, but it's very little work compared to instantiating the module multiple times.

These semantics aren't part of the proposed WASM standard, or supported by this API, but I hope they can be eventually standardized. Based on past discussion and publications), I think the way to standardize this behavior is to:

• Add a shared flag to all WASM extern types: functions, globals, tables, etc.
• Extend the shared flag with a third value denoting thread_local for globals.
• Require shared functions, tables, and globals to only reference shared or thread_local externs.
• Add a shared flag to the module that requires all imports/exports to be shared, and allows instances of the modules to shared between threads.

This allows the type system to encode, for example, that imports from JavaScript are non-shared and may not be called from shared functions/instances.

For non-browser embeddings, it's fine to just say that if your embedding creates multiple threads, you need to make sure that any host functions you export to the WASM code are thread-safe. Browsers need a way to enforce that constraint.

If this API were to eventually support shared functions/instances, then I would suggest that wasm_func_call should take a wasm_store_t* parameter. That would allow the runtime to use the same wasm_func_t* for every wasm_store_t. Similarly, wasm_global_get/wasm_global_set should take a wasm_store_t* parameter to allow getting/setting thread-local variables without allocating a distinct wasm_global_t* for each thread.

Splitting wasm_store_t into shared state and thread-local state is also important to allow running multiple isolated programs in a single OS process. They allow decoupling garbage collection for each compartment, and factoring the O(threads * thread-locals) work and space into smaller per-compartment products.

from wasm-c-api.

@AndrewScheidecker, it's even more complicated than that: you'll also need to put a shared attribute on reference types and corresponding typing rules, you'll want new atomic instructions to access the shared state, and you need a memory model for all that. See our upcoming OOPSLA paper, which adds all these things. The upshot is that that would also enable adding a fork instruction to Wasm.

So to answer the original question: allowing shared instances would require a substantial set of extensions to Wasm itself. I don't see these all being added anytime soon, so sharing instances is out of reach for the API for the time being.

from wasm-c-api.

Does it means that the only way to run wasm module in multithreaded process is to initialize it in each individual thread? The problem is that in case of v8 it takes several MB for each module instance.

from wasm-c-api.

@geloizi, yes. Same as on the Web.

A module instance of several MB sounds like a lot. A small instance should have a small memory footprint. What's in that module?

from wasm-c-api.

https://github.com/v8/v8/blob/master/samples/hello-world.cc

In this example what v8 objects could be shared by multiple threads?

from wasm-c-api.