`poll`/`select` with POSIX (web)socket blocks indefinitely

[stevenwdv]

poll/select waiting for data on an emulated POSIX TCP socket over a web socket blocks indefinitely, or until the timeout is reached, instead of resuming when data arrives. (Before v4.0.23, blocking was not supported, see #25523/#25990.)

I used test/sockets/test_sockets_partial_client.c as test program.

Command:

emcc -v ./test_sockets_partial_client.c -o./test_sockets_partial_client -DSOCKK=12345 -pthread -sPROXY_TO_PTHREAD -sEXIT_RUNTIME && npm install ws && ./test_sockets_partial_client

Output

 /home/swdv/emsdk/upstream/bin/clang -target wasm32-unknown-emscripten -fignore-exceptions -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr --sysroot=/home/swdv/emsdk/upstream/emscripten/cache/sysroot -D__EMSCRIPTEN_SHARED_MEMORY__=1 -DEMSCRIPTEN -Xclang -iwithsysroot/include/fakesdl -Xclang -iwithsysroot/include/compat -v -DSOCKK=12345 -pthread -c ./test_sockets_partial_client.c -o /tmp/emscripten_temp_o68zyf28/test_sockets_partial_client.o
clang version 23.0.0git (https:/github.com/llvm/llvm-project 358db292cc6a9a8a5448a296f643312289f328d7)
Target: wasm32-unknown-emscripten
Thread model: posix
InstalledDir: /home/swdv/emsdk/upstream/bin
 (in-process)
 "/home/swdv/emsdk/upstream/bin/clang-23" -cc1 -triple wasm32-unknown-emscripten -emit-obj -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name test_sockets_partial_client.c -mrelocation-model static -mframe-pointer=none -ffp-contract=on -fno-rounding-math -mconstructor-aliases -target-feature +atomics -target-feature +bulk-memory -target-feature +mutable-globals -target-feature +sign-ext -target-cpu generic -fvisibility=hidden -debugger-tuning=gdb -fdebug-compilation-dir=/home/swdv/webtest -v -fcoverage-compilation-dir=/home/swdv/webtest -resource-dir /home/swdv/emsdk/upstream/lib/clang/23 -D __EMSCRIPTEN_SHARED_MEMORY__=1 -D EMSCRIPTEN -D SOCKK=12345 -isysroot /home/swdv/emsdk/upstream/emscripten/cache/sysroot -internal-isystem /home/swdv/emsdk/upstream/lib/clang/23/include -internal-isystem /home/swdv/emsdk/upstream/emscripten/cache/sysroot/include/wasm32-emscripten -internal-isystem /home/swdv/emsdk/upstream/emscripten/cache/sysroot/include -ferror-limit 19 -fmessage-length=229 -pthread -fgnuc-version=4.2.1 -fskip-odr-check-in-gmf -fignore-exceptions -fcolor-diagnostics -iwithsysroot/include/fakesdl -iwithsysroot/include/compat -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr -o /tmp/emscripten_temp_o68zyf28/test_sockets_partial_client.o -x c ./test_sockets_partial_client.c
clang -cc1 version 23.0.0git based upon LLVM 23.0.0git default target x86_64-unknown-linux-gnu
ignoring nonexistent directory "/home/swdv/emsdk/upstream/emscripten/cache/sysroot/include/wasm32-emscripten"
#include "..." search starts here:
#include <...> search starts here:
 /home/swdv/emsdk/upstream/emscripten/cache/sysroot/include/fakesdl
 /home/swdv/emsdk/upstream/emscripten/cache/sysroot/include/compat
 /home/swdv/emsdk/upstream/lib/clang/23/include
 /home/swdv/emsdk/upstream/emscripten/cache/sysroot/include
End of search list.
 /home/swdv/emsdk/upstream/bin/clang --version
 /home/swdv/emsdk/upstream/bin/wasm-ld -o ./test_sockets_partial_client.wasm /tmp/tmp51y0abp3libemscripten_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=_emscripten_thread_free_data --export=_emscripten_thread_crashed --export=__funcs_on_exit --export=__wasm_call_ctors --export=_emscripten_tls_init --export=_emscripten_thread_init --export=_emscripten_stack_restore --export=emscripten_stack_set_limits --export=_emscripten_thread_exit --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 --entry=_emscripten_proxy_main --stack-first --table-base=1 /tmp/emscripten_temp_o68zyf28/test_sockets_partial_client.o -L/home/swdv/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten -L/home/swdv/emsdk/upstream/emscripten/src/lib /home/swdv/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/crtbegin.o /home/swdv/emsdk/upstream/emscripten/cache/sysroot/lib/wasm32-emscripten/crt1_proxy_main.o -lGL-mt-getprocaddr -lal -lhtml5 -lstubs-debug -lc-mt-debug -ldlmalloc-mt-debug -lcompiler_rt-mt -lc++-debug-mt-noexcept -lc++abi-debug-mt-noexcept -lsockets-mt -mllvm -combiner-global-alias-analysis=false -mllvm -enable-emscripten-sjlj -mllvm -disable-lsr
 /home/swdv/emsdk/upstream/bin/llvm-objcopy ./test_sockets_partial_client.wasm ./test_sockets_partial_client.wasm '--remove-section=.debug*' --remove-section=producers --remove-section=name
 /home/swdv/emsdk/node/22.16.0_64bit/bin/node /home/swdv/emsdk/upstream/emscripten/tools/compiler.mjs -

I'm running https://github.com/vi/websocat as WebSocket server on localhost:12345 (./websocat.x86_64-unknown-linux-musl -vvv -s 12345) and can see the incoming connection, but when I try to reply, the client never unblocks. The same holds when running in the browser.

When I replace the timeout by struct timeval noblock = {};, it receives my reply in the browser, but not in Node.js. Should I file the latter as a separate issue? I've had sockets work with Node.js though, so I may be doing something wrong..?

Version

emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 5.0.0 (a7c5dea)

[sbc100]

I think maybe the change in #25523 added blocking support for pipes, but not for anything else (such as sockets and files).

I imagine there is more work to do extend that support to sockets.

[sbc100]

@ktock, I think perhaps in #25523 we should have created a new stream_ops.pollAsync rather than modify the existing stream.ops.poll, that we wouldn't accidentally break existing providers of stream_ops.poll such as libsockfs.js.

[stevenwdv]

I see.
To be clear btw, I think it's awesome that blocking is finally being implemented :), see my earlier issue #25759. I hope web sockets also gain support soon.

[ktock]

How about introducing stream.stream_ops.asyncPoll as a boolean flag so that the select can know whether the backend supports the callback? If stream.stream_ops.asyncPoll is false and the select is called with a non-zero timeout (i.e timeout is NULL or it contains non-zero value), select will immediately return with EINVAL (or return immediately without an error, if we want to preserve the previous behaviour).

[sbc100]

Historically JS API (such as those found in node) have separate sync and async APIs (rather then trying to make a single API that can be both sync and async). I think it would make sense to follow that tradition, but mabye there are is some technical or ergonomic reason not to in this case. I imagine it will become clear once we implement this.