Can/should we make emscripten_futex_wait/wake API work in Wasm Workers.

[sbc100]

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.

[sbc100]

I think as part of this we should also be able to make emscripten_is_main_runtime_thread work.

[sbc100]

CC @cwoffenden @juj

[sbc100]

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]

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.

Perhaps the pthread functions should assert in debug mode if they are ever called from a wasm worker?

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]

(before the combined pthread+wasm worker build mode, we would never link the pthread code, so that would deal with that issue automatically)

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.

[juj]

With pure wasm workers we link the stub versions of pthread API don't we?

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.