Repository navigation
Can/should we make emscripten_futex_wait/wake API work in Wasm Workers. #26314
Description
Its doesn't seem like it should be hard to make them work.
It would help us fix things like #26283, and avoid issues like #26309 where folks might think the API was actually working.
Since #21618 it has been possible to call the API when both Wasm Workers and pthreads were enabled, but not when only Wasm Workers is used.
Activity
sbc100 commentedon Feb 20, 2026
I think as part of this we should also be able to make
emscripten_is_main_runtime_threadwork.sbc100 commentedon Feb 20, 2026
CC @cwoffenden @juj
sbc100 commentedon Feb 23, 2026
Another thing we should perhaps do is not define pthread stub function at all when building with wasm workers.
The pthread stub functions assume that they are being used in single threaded constext and should be used from wasm workers. Better to not define them at all maybe when wasm workers are enabled.
What about then both wasm workers and pthreads are defined? Perhaps the pthread functions should assert in debug mode if they are ever called from a wasm worker?
juj commentedon Feb 24, 2026
I'm all for making emscripten_futex_wait/wake API work in Wasm Workers, but I do feel strongly that it should be made in a way that does not creep the unconditional code size abstractions into the baseline overhead of Wasm Workers.
Agreed, after adding the combined pthread+wasm worker build mode, there is now this gap where if one does call many of the unsupported pthread functions from inside a wasm worker, issues will silently occur. A debug assert would be a great idea to help developers detect these issues.
(before the combined pthread+wasm worker build mode, we would never link the pthread code, so that would deal with that issue automatically)
sbc100 commentedon Feb 24, 2026
Is that true though? With pure wasm workers we link the stub versions of pthread API don't we? and they can silently succeed I think, because they assume the app they are linked into is single threaded.
Improve emscripten_futex_wait stub. NFC (#26309)
Enable emscripten_futex API for Wasm Workers (#26325)
juj commentedon Feb 25, 2026
Ohh, I didn't recall that. I thought we'd not link in anything pthreads in Wasm Workers mode, so that it would result in a link error.
Iideally we'd already croak at
#include <pthread.h>to get compile time errors (unless we want to go down the route of partial pthread API impls on Wasm Workers), since that would explicitly make all the pthread stuff unavailable and ensure people aren't leaning on to the stubs. Though that would be a bit of include path wrangling.[WASM_WORKERS] Don't define pthread function in WASM_WORKERS builds (#…