mirror of
https://github.com/ruby/ruby.git
synced 2026-08-16 12:57:31 +08:00
6e055f5692
Some fast_fallback tests inject an artificial delay to test timing-sensitive behavior. Under CI's parallel test execution, threadscheduling jitter can make the delay longer than expected, and in that case these tests may fail to connect to the server process they are actually supposed to connect to. For example: 1. The IPv6 name resolution is artificially delayed by 25ms, so the IPv4 name resolution succeeds first. 2. If the IPv6 name resolution succeeds within 25ms, the client starts connecting to the `::1` server process and the test passes. However, if the IPv6 name resolution is delayed by more than 50ms for some reason, fast_fallback starts connecting to `127.0.0.1` instead, by design. 3. If another test happens to have a server listening on `127.0.0.1` with the same port number, the connection accidentally succeeds. 4. The `::1` server process is left waiting, and the thread cleanup hangs. To address this, the listening server process now receives the result of `accept` through a local variable instead of `Thread#value`. On success, it joins the thread with a short timeout; otherwise, it terminates the thread with `Thread#kill.join`. This change is expected to prevent hangs even when such a wrong connection occurs.