On the shared listen fd one worker takes nearly every connection, always the same one #329

On the shared listen fd — the default outside Linux and FreeBSD, and the second Linux CI run through TRUE_ASYNC_SERVER_SHARED_LISTEN_FD=1 — connections opened one after another go almost entirely to one worker, in a fixed direction. #240 settled that the server promises nothing about which worker accepts; these numbers are of a different kind than #240's single [1,0,8] under taskset -c 0, so they are recorded here rather than by reopening it.

Measured on 2026-09-29

Linux (WSL2, 16 CPUs, idle), 2 workers, 32 connections opened one after another, final split first:second:

On the shared fd every WebSocket run gives the majority to the second worker; on SO_REUSEPORT the direction varies. The cause is not traced. What would establish it: the same probe with 3 workers (does the last one always win), and strace -f -tt -e trace=epoll_wait,accept4 recording, per connection, whose epoll_wait returns first and whose accept4 gets EAGAIN.

Consequence

On macOS, where the shared fd is the default, setWorkers(N) serves sequential clients with essentially one worker. websocket/064–066, which need a subscriber on every worker, now skip on the shared fd (they failed there three times in two runs of PR #328).

Question

Does "the server promises nothing about the accept split" (#240) still hold with this measurement, or is an even-enough split on the shared fd a goal? No fix is proposed before the cause is traced.