`std::call_once` does not work with `WASM_WORKER` due to dependency on pthread APIs.

[sbc100]

libc++ call_once currently depend on pthread APIs, which currently makes std::cout unusable under WASM_WORKERS:

$ cat test.cpp
#include <iostream>

int main() {
  std::cout << "hello" << std::endl;
  return 0;
}
$ ./emcc -sWASM_WORKERS test.cpp
wasm-ld: error: /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/lib/wasm32-emscripten/libc-ww-debug.a(__tz.o): undefined symbol: pthread_mutex_lock
wasm-ld: error: /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/lib/wasm32-emscripten/libc-ww-debug.a(__tz.o): undefined symbol: pthread_mutex_unlock
wasm-ld: error: /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/lib/wasm32-emscripten/libc++-debug-ww-noexcept.a(call_once.o): undefined symbol: pthread_mutex_lock
wasm-ld: error: /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/lib/wasm32-emscripten/libc++-debug-ww-noexcept.a(call_once.o): undefined symbol: pthread_cond_wait
wasm-ld: error: /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/lib/wasm32-emscripten/libc++-debug-ww-noexcept.a(call_once.o): undefined symbol: pthread_mutex_unlock
wasm-ld: error: /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/lib/wasm32-emscripten/libc++-debug-ww-noexcept.a(call_once.o): undefined symbol: pthread_mutex_lock
wasm-ld: error: /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/lib/wasm32-emscripten/libc++-debug-ww-noexcept.a(call_once.o): undefined symbol: pthread_mutex_unlock
wasm-ld: error: /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/lib/wasm32-emscripten/libc++-debug-ww-noexcept.a(call_once.o): undefined symbol: pthread_cond_broadcast
wasm-ld: error: /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/lib/wasm32-emscripten/libc++-debug-ww-noexcept.a(call_once.o): undefined symbol: pthread_mutex_unlock
emcc: error: '/usr/local/google/home/sbc/dev/wasm/llvm-build/bin/wasm-ld -o a.out.wasm /tmp/tmpqge8uk99libemscripten_js_symbols.so --import-memory --shared-memory --strip-debug --export=emscripten_stack_get_end --export=emscripten_stack_get_free --export=emscripten_stack_get_base --export=emscripten_stack_get_current --export=emscripten_stack_init --export=_emscripten_stack_alloc --export=__wasm_call_ctors --export=_emscripten_stack_restore --export=_emscripten_wasm_worker_initialize --export-if-defined=__start_em_asm --export-if-defined=__stop_em_asm --export-if-defined=__start_em_lib_deps --export-if-defined=__stop_em_lib_deps --export-if-defined=__start_em_js --export-if-defined=__stop_em_js --export-if-defined=main --export-if-defined=__main_argc_argv --export-if-defined=fflush --export-table -z stack-size=65536 --no-growable-memory --initial-memory=16777216 --no-entry --stack-first --table-base=1 /tmp/emscripten_temp_yna_2mqo/test.o -L/usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/lib/wasm32-emscripten -L/usr/local/google/home/sbc/dev/wasm/emscripten/src/lib /usr/local/google/home/sbc/dev/wasm/emscripten/cache/sysroot/lib/wasm32-emscripten/crtbegin.o -lGL-ww-getprocaddr -lal -lhtml5 -lstubs-debug -lnoexit -lc-ww-debug -ldlmalloc-ww-debug -lcompiler_rt-ww -lc++-debug-ww-noexcept -lc++abi-debug-ww-noexcept -lsockets-ww --whole-archive -lwasm_workers-debug --no-whole-archive -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr' failed (returned 1)

See #26283

[sbc100]

It looks like std::once depends on the internal __libcpp_mutex_lock API, which currently has backends for C11 threads, pthreads and windows threads.

To make this work we would either needs to:

1. Create a new __libcpp_mutex backend based on emscripten atomics/futex.
2. Make pthread_mutex work under wasm workers.
3. ??

[sbc100]

@juj WDYT?

[juj]

2. Make pthread_mutex work under wasm workers.

pthread_mutex is a bit of a can of worms, I think it will be annoying code dependency creep to get going.

Peeking at __libcpp_mutex API though, that seems like a simpler alternative to route to the current wasm_worker.h primitives?

[sbc100]

Yes, that is what option (1) is, right?

We would basically need to build out own lock primitive for Wasm Workers. That also sounds like kind of can of worms, but certainly possible.

Also, the resulting primitive would need to work under pthreads and wasm workers both since it would need to work in the hybrid case. So it should not be specific to work workers (just like emscripten_futex works on both wasm workers and pthreads)

[juj]

Yes, that is what option (1) is, right?

Yeah, exactly.

Also, the resulting primitive would need to work under pthreads and wasm workers

Uhh, right.. yeah, that could be a bit annoying.