Repository navigation
A Windows worker pool serves from one worker #375
Description
With setWorkers(N) on Windows, worker 0 accepts nothing and the worker started last takes most or all connections.
Probe: 30 concurrent curl requests, each handler Async\delay(200), requests per worker from getStats(), local Windows Release ZTS build:
| Workers | Runs | Requests per worker, worker 0 first |
|---|---|---|
| 2 | 5 | 0/30 in all 5 |
| 3 | 20 | 0/0/30 in 13; 0/1/29 and 0/20/10 twice each, 0/5/25, 0/16/14, 0/17/13 |
| 4 | 5 | 0/0/0/30 in all 5 |
Worker 0 accepted nothing in 30 of 30 runs. telemetry/012 (48 connections held over 8 rounds, 3 workers) saw no spread in 10 of 10 runs.
Each worker listens on its own duplicate of the shared socket (http_server_class.c, the shared-fd branch). Candidate causes, none checked yet: the order in which Winsock completes AcceptEx across duplicates, php-async posting one AcceptEx at a time (true-async/php-async#307), or the reactor.
USAGE.md:688 explains the limit with "libuv falls back to a single accept thread", which the probe contradicts: two workers accepted in 7 of 30 runs.
Activity
EdmondDantes commentedon Oct 6, 2026
Closing after checking CPU scaling on a fresh Windows Release ZTS build (server 0f2c023, PHP 863f6dd9, php-async 9a89434, libuv 1.49.3). Three runs per setting, 512 fresh HTTP/1.1 connections with 32 concurrent clients and 30000 SHA-256 iterations per request: median throughput was 12.88 / 21.45 / 36.13 requests/s for 1 / 2 / 4 workers. Process CPU usage was 1.00 / 1.99 / 3.90 cores. Every worker handled a substantial share of CPU work; four workers improved throughput by 2.81x. The light Async delay(200) scenario still gives uneven connection distribution, but all 30 responses completed in approximately 220 ms. These checks do not demonstrate lost CPU parallelism or justify changing the current per-worker reactor topology. Closing at the maintainer request; the observed accept-distribution bias remains acknowledged.