Making thread-local initialization explicit

[tlively]

One of the biggest problems identified with thread-local globals so far is the complexity and cost of ensuring they are initialized before they are used. One option we've considered is eagerly initializing the TLS for every instance when a new thread is created and eagerly creating the TLS for every thread when a new instance is created. This obviously scales very poorly. The other option we've considered is initializing TLS lazily upon entering a particular instance on a particular thread for the first time, but that would slow down all indirect calls because they would have to check whether they are crossing an instance boundary and need to initialize TLS.

I recently developed an idea for another option, which is to give up on ensuring that thread-local storage is available by the time it is accessed, and instead trap if it has not been explicitly initialized yet for the current thread. This was always going to be what happened when you called a thread-bound imported JS function before binding it on the current thread, so the new idea is to extend that pattern to thread-local globals as well. This semantics means that we need neither expensive eager initialization nor expensive lazy initialization, and ideally the initialization check on access could be made fast by using a trap handler.

The API for this explicit instantiation could be attached to some kind of shareable handle to a Module/Instance hybrid. This handle would be vended by a WebAssembly.Instance and could provide access to the shared exports of the instance on any thread, but it would only provide access to the unshared exports (if any) on a thread once it has been instantiated with the unshared and thread-local imports on that thread. The TLS would be allocated and initialized as part of this per-thread instantiation.

This would be essentially committing to the instance-per-thread model, at least as far as TLS is concerned. My hope is that this will be acceptable in the component model because the thread.spawn builtin will be able to identify any necessary thread-local imports from the thread-local reflection of the module/instance graph and can be specified as invoking the embedder API for doing the per-thread instantiation.

[tlively]

cc @abrown

[eqrion]

Sorry I missed this back in June.

The API for this explicit instantiation could be attached to some kind of shareable handle to a Module/Instance hybrid. This handle would be vended by a WebAssembly.Instance and could provide access to the shared exports of the instance on any thread, but it would only provide access to the unshared exports (if any) on a thread once it has been instantiated with the unshared and thread-local imports on that thread. The TLS would be allocated and initialized as part of this per-thread instantiation.

This would be essentially committing to the instance-per-thread model, at least as far as TLS is concerned. My hope is that this will be acceptable in the component model because the thread.spawn builtin will be able to identify any necessary thread-local imports from the thread-local reflection of the module/instance graph and can be specified as invoking the embedder API for doing the per-thread instantiation.

I'm a little confused what this would look like. Could you elaborate with some pseudo code?

[tlively]

// main thread
let {module, instance} = await WebAssembly.instantiateStreaming(source, js_imports);
let sharedInstance = instance.getSharedInstance(); // Provides only shared exports.
postMessage(sharedInstance, worker); // Send the shared instance to a worker.

// Worker, upon receiving the shared instance.
let instance = sharedInstance.instantiateThreadLocal(js_imports); // Get a full instance.

[eqrion]

@tlively

I see, thanks. So instantiateThreadLocal would both make fresh instantiations of the unshared definitions and also explicitly initialize the thread-local globals? So if you called a shared function before this step would there be a trap? (is that trap if the thread-local global is used in that module, or only if it's used in that function?)

Is there a variant of this which doesn't instantiate the unshared definitions and just does the explicit initialization of thread-local state? That seems like the new capability here, because you already could split your module into a shared module imported by the unshared module. And the unshared module could be instantiated per-thread.

[tlively]

So instantiateThreadLocal would both make fresh instantiations of the unshared definitions...

Probably not, see below. I guess the "Get a full instance" comment in the example was misleading.

...and also explicitly initialize the thread-local globals?

Yes, and would also populate thread-local function imports if we have those in addition to the thread-local globals.

So if you called a shared function before this step would there be a trap? (is that trap if the thread-local global is used in that module, or only if it's used in that function?)

In general calling a shared function before this step can succeed. The trap would only occur if the shared function ends up accessing a thread-local global or calling a thread-local function import before it has been instantiated by this API call on the current thread.

Is there a variant of this which doesn't instantiate the unshared definitions and just does the explicit initialization of thread-local state?

Yes, this is actually what I had in mind. It would be odd to create new instantiations of the unshared definitions (i.e. a separate second instance) without also creating new instantiations of the shared definitions. But as you say, you can already create instances of a module on multiple threads, so that wouldn't be a new capability.