Enable emscripten_futex API for Wasm Workers

[sbc100]

This involves also including emscripten_thread_state.S which provides
APIs such as emscripten_is_main_runtime_thread and
emscripten_is_main_browser_thread` which now also work in Wasm Workers.

There is a minor code size hit here of ~80 bytes, but I think its
worth it to have these low level APIs available everywhere.

Depends on: #26309
Fixes: #26314

[sbc100]

Can you also take a look at #26309 which this change depends on ?

[juj]

There is a minor code size hit here of ~80 bytes, but I think its
worth it to have these low level APIs available everywhere.

Maybe a better approach would be to implement emscripten_futex_wait/wake in terms of emscripten_atomic_wait_u32() and emscripten_atomic_notify() without bringing the overhead? The overhead here is about POSIX emulation, and avoiding that was exactly why Wasm Workers exists.

[sbc100]

There is a minor code size hit here of ~80 bytes, but I think its
worth it to have these low level APIs available everywhere.

Maybe a better approach would be to implement emscripten_futex_wait/wake in terms of emscripten_atomic_wait_u32() and emscripten_atomic_notify() without bringing the overhead? The overhead here is about POSIX emulation, and avoiding that was exactly why Wasm Workers exists.

I think they overhead is more about being able to run on the main thread.

emscripten_atomic_wait_u32 doesnt' work on the main thread, so emscripten_futex_wait instead has to busy wait on the main thread.

So at the very least we need to have _emscripten_thread_supports_atomics_wait working in wasm workers so we can know if its safe to call emscripten_atomic_wait_u32 or not.

[sbc100]

OK, I jumped through some hoops to ensure that the cost of tracking the tread state is only payed for programs that use these APIs.

[sbc100]

@dschuff @kripken PTAL, this doesn't have the code size regression anymore so should no issue I hope.

[juj]

I wonder if there might be a solution that would use the __postset construct, with a

init_thread_state__postset: '__do_set_thread_state()',
emscripten_futex_wait__deps: ['init_thread_state'],
emscripten_futex_wake__deps: ['init_thread_state'],
emscripten_is_main_runtime_thread__deps: ['init_thread_state'],
emscripten_is_main_browser_thread__deps: ['init_thread_state'],

This way we would avoid the complexity of the lazy init, but still, only emit the thread state initialization if any of the functions needing it would be called?

[sbc100]

That sounds like a good idea if it could be made to work.

Its tricky because those function are not JS function so they can't currently have __deps entries like that.

But yes, it would be good find a solution that was dependency graph based rather than based on a runtime flag.

[sbc100]

Also this "thread state" is just a handful of wasm globals so I'm hoping maybe the cost if very marginal for real programs.