Support blocking socket ops via a single fd_wait primitive - #27342
Support blocking socket ops via a single fd_wait primitive#27342guybedford wants to merge 5 commits into
Conversation
ab5b071 to
c6bfc66
Compare
d305cb6 to
4b28cc5
Compare
guybedford
changed the title
afad990 to
676365f
Compare
Blocking accept/recv on sockets, replacing the previous approach of marking the socket data syscalls __async (which, under JSPI, wrapped every one of them in WebAssembly.Suspending - taxing every nonblocking call with a suspend/resume round-trip, since a Suspending import always resolves through a Promise in V8). The data syscalls stay strictly synchronous imports: single attempt, -EAGAIN when they would block. Blocking is factored into one new import, _emscripten_fd_wait(fd, events), and retry loops in the musl wrappers (accept, accept4, recvfrom, recvmsg): on EAGAIN with a blocking fd and no MSG_DONTWAIT, wait for readiness on the inode's listener queue and retry. This is a pthreads-only facility. The retry loops compile only into the -mt libc (gated on __EMSCRIPTEN_PTHREADS__ - the only compile-time boundary libc has; ASYNCIFY is a link-time transform with no libc variant), and _emscripten_fd_wait blocks only on a proxied pthread worker: __proxy sync + __async gives the PROXY_SYNC_ASYNC call path, whose sync-proxy completes - ending the worker's futex wait - when the returned Promise resolves. In every other context, including the event-loop thread which cannot block, it fails with -EAGAIN. Single-threaded ASYNCIFY/JSPI builds use epoll for readiness instead, so a purely-synchronous build keeps the direct doReadv/doWritev path byte-for-byte and hello-world code size is unchanged. accept4 now applies SOCK_NONBLOCK to the accepted fd (on top of the flags it inherits from the listener); without this a SOCK_NONBLOCK accept off a blocking listener wrongly yielded a blocking socket. Send/write paths are untouched: the node backend buffers and never would-blocks, so blocking send degenerates to synchronous buffered success and needs no wait machinery. read()/write() on a socket fd are likewise not covered - only the socket calls themselves. Tested with test_noderawsockets_tcp_blocking (blocking accept + recv that must suspend, under PROXY_TO_PTHREAD) and test_noderawsockets_tcp_accept_nonblock (accept4 SOCK_NONBLOCK off a blocking listener), plus the mio test suite under PROXY_TO_PTHREAD + NODERAWSOCKETS + NODERAWFS: 144 passed, 0 failed, 5 ignored.
676365f to
c187b60
Compare
…pport - Move _emscripten_fd_wait to libfs.js (not a syscall; drops __nothrow). - Fold the O_NONBLOCK check into the primitive and return a boolean, so the libc retry loop makes a single JS call. - Support single-threaded ASYNCIFY/JSPI by suspending the calling stack, mirroring __syscall_poll; the retry loop now compiles into every libc variant, with a no-op stub for WASMFS. - Declare _emscripten_fd_wait only in emscripten_internal.h; add the copyright header; drop the _cp suffix from the retry macro. - Move the ChangeLog entry to 6.0.9; add a JSPI variant of the blocking test. - Rebaseline hello_dylink_all codesize.
c187b60 to
b740cea
Compare
guybedford
changed the title
sbc100
left a comment
sbc100
left a comment
There was a problem hiding this comment.
Out of interest if we could find a way to integrate this behaviour directly into the existing syscalls without a separate _emscripten_fd_wait call, would that work for you?
I guess my question really is: How much would it matter if these syscalls were all JSPI-promising? i.e. if they always return a promise even when data is ready? Is the syncronous already-ready case important for performance? If the answer is yes, and I guess JSPI really made the wrong decision by going with the always-promising/always-a-microtask model for async imports.
sbc100
left a comment
sbc100
left a comment
There was a problem hiding this comment.
This change seems to mirror/duplicate the pattern used in poll/select with __syscall_poll_nonblocking followed by the normal poll.
I wonder if we could some up with a single unified solution here?
I guess I wouldn't mind landing this as-as with some kind of plan to unify later once we understand the problem space better (since all this is internal stuff anyway we can change it in the fugure).
Also, I'd like to get #26964 landed one day which I think we could use to implement a generic maybe-async function, where all of these syscalls would return a pair or <result, Promise>.. then we would only suspend when the promise was non-null, or something like that.
Then maybe in async-available builds all syscalls could return this pair and we could make this work transparently for all syscalls?
Yes this does matter quite a bit - microtask round trips are generally expensive, and the sync code is very much desired for a hot path. For what it's worth various important semantics properties are maintained by the always-promising behavior, so I personlly think the host-management is not a terrible situation here.
Yes poll/epoll could themselves be re-expressed as nonblocking derive followed by an fd_wait on the set, with the result, promise pair from #26964 letting the syscall itself return the wait instead of requiring a retry. This does seem like a sensible and natural follow-on. |
2 participants
Adds support for blocking socket ops (
accept,accept4,recv,recvfrom,recvmsg) wherever the calling stack can suspend - secondary pthreads (includingmain()underPROXY_TO_PTHREAD), and single-threadedASYNCIFY/JSPIbuilds - via a single_emscripten_fd_wait(fd, events)primitive.The data syscalls stay strictly synchronous imports: single attempt,
-EAGAINwhen they would block. Blocking is factored into retry loops in the musl wrappers (via a shared__emscripten_sock_retryhelper documenting the convention): onEAGAINwith noMSG_DONTWAIT, call_emscripten_fd_waitand retry if it returns true._emscripten_fd_waitreturns false without waiting when the fd is non-blocking or there is no stack to suspend, so theEAGAINsurfaces unchanged. Otherwise it waits for readiness on the inode's listener queue, mirroring__syscall_poll:PROXY_SYNC_ASYNC): a secondary thread parks on its sync-proxy futex until the readiness promise resolves on the main thread. The main browser thread itself cannot block, so there it fails.ASYNCIFY/JSPIthe calling stack suspends on the same promise.The retry loops compile into every libc variant; WASMFS (no socket support) carries a no-op stub.
Only the receive-side socket calls are covered:
send/writenever block (the Node.js backend buffers), and a blockingread()/write()on a socket fd is out of scope.accept4now also appliesSOCK_NONBLOCKon top of the flags inherited from the listener; previously aSOCK_NONBLOCKaccept off a blocking listener wrongly yielded a blocking socket.Tested with
test_noderawsockets_tcp_blocking(blocking accept + recv that must suspend) under bothPROXY_TO_PTHREADandJSPI, andtest_noderawsockets_tcp_accept_nonblock, plus the mio suite underPROXY_TO_PTHREAD+NODERAWSOCKETS+NODERAWFS: 144 passed, 0 failed, 5 ignored.Made with AI assistance under my review.