[guybedford]

This makes blocking accept(), recv(), recvfrom() and recvmsg() on JS-backed sockets actually block wherever the calling stack can wait: a sync-proxied pthread (including main() under PROXY_TO_PTHREAD), or ASYNCIFY/JSPI. Previously these returned EAGAIN on a blocking fd regardless.

The three syscalls become __async: 'auto' library functions taking the sync argument of #28022. The backends stay strictly synchronous and throw EAGAIN when they would block; a shared sockCall helper in libsyscall.js runs the syscall body, and on EAGAIN for a blocking fd (no O_NONBLOCK, no MSG_DONTWAIT) with sync false returns a Promise that parks on the socket's inode wait-queue (the same queue poll()/epoll use) until it reports readable, hung up or errored, then retries. A proxied pthread caller awaits that Promise; ASYNCIFY/JSPI suspend on it. Where no stack can wait (sync true: the event-loop thread itself) the EAGAIN surfaces unchanged, with the ASSERTIONS warning moved from the node backend to this layer.

• TCP recvmsg in the node backend now returns and clears a pending socket error (as the dgram branch already did, and as Linux does) instead of EAGAIN, so a blocked recv() woken by a connection error returns that error rather than spinning. The error takes precedence over EOF, since node emits 'close' right after 'error'.
• MSG_DONTWAIT is added to struct_info for the recv flag check. No libc changes.
• A sync-proxied __async: 'auto' body that returns a plain value is delivered to the pthread on the spot rather than through a microtask. Microtasks only run when the main thread returns to its event loop, which a main() blocked in pthread_join (or a mutex, or sleep) never does, though its futex wait still runs proxied calls; the pthread would wait forever on a call that had already completed. sockCall tries the operation synchronously first and only parks on a would-block, so an accept() or recv() that can complete at once does. Under JSPI the main-thread wrapper of an 'auto' body likewise hands a proxied call's result back directly instead of through the async helper, which would wrap even a plain value in a Promise.

Tested with test_noderawsockets_tcp_blocking (non-blocking/MSG_DONTWAIT EAGAIN, blocking accept() woken by a late connection, blocking recv() woken by data and by peer close, and already-ready calls returning without waiting) and test_noderawsockets_tcp_blocking_error (blocking recv() woken by an injected connection error, SO_ERROR cleared after), each under PROXY_TO_PTHREAD, JSPI and ASYNCIFY. test_noderawsockets_tcp_blocking_join is a plain -pthread build where main() sits in pthread_join on a thread whose accept() and recv() have a connection and data already pending; it hangs without the synchronous completion, in both the plain and the JSPI build. test_nonblock_flags drops its assertion that a blocking accept() would-blocks.

Made with AI assistance under my review