"Solving" TLS by doing nothing

La issue è una discussione di progettazione sulle funzioni condivise, TLS, le continuazioni condivise e il comportamento di un’istanza per thread in WebAssembly; non vengono indicati file, test o punti di ingresso dell’implementazione. Inizia esaminando il contesto della proposta e risolvendo le domande di progettazione aperte prima di tentare l’implementazione, poiché la issue non fornisce criteri concreti di completamento.

I've recently had a couple chats with the V8 team about TLS, and they're rightfully concerned about the necessary complexity, although not to the point of ruling anything out yet. They also made the astute observations that 1) shared functions are the root of all the complexity, as others have already pointed out, and that 2) implementing TLS in the engine ends up looking very much like implementing our current instance-per-thread model in the engine instead of user space.

This also led to the observation that at least for the multithreaded WasmGC use case, we could easily get away without shared functions by using instance-per-thread for functions and vtables and using vtable indices instead of vtable references in object instances. (Dart is in fact already using this strategy today.) That would also give us TLS "for free" in the same way we get TLS for free today, where each thread can simply have its own non-shared globals.

Ignoring shared functions for now is an excellent way to scope down complexity for prototypes and start trying to prove incremental value in the short term, but it leaves a couple problems unaddressed.

First, without shared functions, there can be no shared continuations. This would be very sad, especially for Kotlin, where shared continuations are extremely common at the source level. It's probably not a showstopper for them, though, since they can keep lowering the continuations to normal control flow as they do today.

Second, discarding shared functions and thread-local function imports does nothing to address the problem of Web engines having to support shared-to-unshared references to implement thread-bound data. We might be able to provide some short-term, incremental value without thread-bound data, but my hypothesis remains that we will need it in the long run. If that turns out to be true, then the marginal complexity of supporting shared functions and TLS, including thread-local functions, will be significantly reduced, although the performance questions will remain.

Finally, the non-Web folks who are primarily interested in this proposal so they can have threads without the instance-per-thread model would obviously be unhappy if we continued to require instance-per-thread.

So all in all, I don't think discarding shared functions is going to be the best long-term design, but it will make prototyping much simpler in the near future. We should certainly continue discussing how to effectively support shared functions, TLS, and shared continuations because those remain the biggest open questions we have for the long term.