threads
threads copied to clipboard
WebAssembly
What are the plans for thread-local and shared global variables?
AFAICT for the current web embedding of WebAssembly, globals are effectively thread-local: you have to create a new instance of a module for each JavaScript worker, so any mutable globals will also be duplicated for each worker. Is that correct?
I assume that's not as efficient as allowing instances to be shared between workers, and adding some form of thread-local variables.
Do we need shared global variables? Shared vs thread-local is only meaningful for mutable variables, and mutable shared globals can be lowered to an immutable global address into shared memory, so it might be simpler to just omit shared globals.
On 19 May 2017 at 13:25, Andrew Scheidecker [email protected] wrote:
Do we need shared global variables? Shared vs thread-local is only meaningful for mutable variables, and mutable shared globals can be lowered to an immutable global address into shared memory, so it might be simpler to just omit shared globals.
Complications with dynamic linking aside, that assumes that all values are transparent, such that they safely can be exposed as raw bytes. However, while true in the MVP, that won't remain the case with extensions like foreign pointers, GC types, and potentially others.
I assume that's not as efficient as allowing instances to be shared between workers, and adding some form of thread-local variables.
Unfortunately, I don't think we can allow Instances (and or Tables) to be shared between workers w/o requiring JS engines to implement full cross-window/worker GC (b/c you can have JS -> wasm -> JS -> wasm ... cycles that go between different worker/window JS GC heaps).
Maybe this will be possible in a farther future, though, if we add shared wasm GC objects. Then we could have Modules declare their Instances to be shared which would restrict the types of allowable imports to only other shared GC things so that everything reachable was in the same shared GC heap.
That being said, even with the current thread-locals-via-multiple-Instances design, I think we need a first-class WebAssembly.Global that can be shared between Instances in the same window/worker to implement dynamic linking of thread locals. E.g., this is what we'd need for the heap-stack-pointer.
WebAssembly.Global is not in the current proposal, but I think it would make sense to add. @binji ?
Sorry, I'm a bit confused. I see that we would want to be able to dynamically link the stack pointer, but don't we need mutable imported/exported globals for that? And I don't quite understand how it relates to the threads proposal, if we aren't planning on having shared globals across workers.
I see that we would want to be able to dynamically link the stack pointer, but don't we need mutable imported/exported globals for that?
Exactly; that's what WebAssembly.Global would be: the JS object that represents a mutable global that could be imported/exported.
And I don't quite understand how it relates to the threads proposal, if we aren't planning on having shared globals across workers.
It relates insofar as if you want load-time dynamic linking + threads you'll need this.
OK, but don't you need this for load-time dynamic linking w/out threads? I'm just wondering if this is a separable proposal, or if it only is needed w/ the threading proposal.
Without threads, you can just use global memory for everything; that's why we weren't even going to have globals at all for a while.
OK, now I see. Since memory is now shared, you need some mechanism for thread-local values. We could do this using mutable globals, but we could also do it using multiple memories. Do you recall the reason we didn't allow mutable globals to be imported/exported in the MVP? Was it just to keep it simple?
Right: just to avoid having to define WebAssembly.Global and since it wasn't yet necessary.
Is this something that will be proposed at the upcoming WebAssembly meeting? If so, can we get a design soon? I'd advise to keep it kinda separable so we can drop / change it more easily. It would be good to document what Emscripten does right now.
It would be good to document what Emscripten does right now.
I expect it doesn't support pthreads + load-time dynamic linking. Is that right @juj?
Ops sorry, missed the above ping.
Emscripten currently supports multithreading on asm.js builds through the pthreads API. dlopen is currently not supported in multithread enabled builds, but it would definitely be desirable to have that support. (I wonder what the conversation around that was during the meeting?)
Because WebAssembly.Table is not being proposed to be shareable between agents in the threading MVP, there's not an efficient way to implement dlopen+threads in the threading MVP. Post-threading-MVP, I think there are various ways to allow Table to be shared in constrained ways such that dlopen+threads is efficiently implementable.