How can we have shared imports?

[abrown]

In the engine requirements of shared attributes, we ask: "how can we have shared imports?" Currently, all imports to WebAssembly modules that are based on WASI or Web APIs would not be shared, preventing them from being called in a thread. This severely limits thread utility. In previous conversations we have discussed some ideas for solving this — let's use this topic to record them.

[conrad-watt]

The WASI environment could probably allow many functions to be imported as both shared and non-shared (assuming that these boil down to primitives that could be used concurrently in a native environment).

In an MVP solution, producers would need to accept the restrictions on expressivity (esp. on the Web, given the above) and work around them - one possible scheme:

• Designate one or more threads as "dispatchers", running a non-shared function with access to a shared memory for signalling
• Other threads running a shared function can software-emulate host calls via blocking and signalling the dispatcher thread to carry out the call on the shared function's behalf

EDIT: see my child comment below for a simpler MVP scheme that doesn't require dispatcher threads

As a post-MVP solution (on the Web), we could introduce a mechanism to safely call non-shared functions from shared functions. Taking inspiration from a previous idea by @lukewagner, we could allow non-shared functions to be "wrapped" as shared functions. Wrapped functions would be typed as shared, and calling them would call the underlying non-shared function, with the following restrictions:

• The call will trap if it occurs outside the thread the function was originally wrapped in.
• The wrapped function is a weakref - it does not root the underlying function, and any calls to the wrapped function after the underlying function is collected will trap.

One nice thing about this solution is that it can be JS API only. All wrapped functions end up looking to Wasm just like regular callable functions.

[lukewagner]

Great idea!

[conrad-watt]

@syg pointed out in a recent meeting that there's actually a much simpler MVP solution that doesn't require "dispatcher threads" - it's still ok to pass non-shared references as arguments to a shared function call and store them in local variables, so one could pass in the global JS object (most likely in the form of a JS function that closes over and invokes properties in that object) for the current thread/worker to the entrypoint Wasm call and carry it through subsequent function calls in the Wasm execution.

The post-MVP solution I sketched above may still have value but in light of the above it seems less urgent.

[conrad-watt]

One separate point (and this seems the best existing issue to make it) - the current overview doesn't correctly describe the behaviour of non-shared Wasm state (what about thread local storage?).

Shared functions will only have access to the parts of the module marked as shared - e.g. attempting to access a non-shared global from a shared function would be a validation error. So non-shared state can't be used for thread-local storage. Instead, thread-local storage has to be allocated in a shared Wasm linear memory (as already needs to happen with address-taken local variables when compiling C/C++ to Wasm) and the current thread id (as handed out here) is used to address the allocation corresponding to the current thread (I'm told this is similar to how thread local storage works natively, especially in dynamic linking scenarios).

A post-MVP extension could add language-level thread-local storage, but we'd need to be careful about the semantics.

[abrown]

Ah, yes! I had some vague apprehension that I was remembering things incorrectly when I wrote this section. Let me update it: #9.

[abrown]

This is now fixed in Overview.md.