gh-156070: Fix operator precedence in multiprocessing's batched Windows wait - #156071

The following commit authors need to sign the Contributor License Agreement:

• 72524975+ekanshul@users.noreply.github.com

A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated.

Once you have made the requested changes, please leave a comment on this pull request containing the phrase I have made the requested changes; please review again. I will then notify any core developers who have left a review that you're ready for them to take another look at this pull request.

Added a regression test in TestWait.test_exhaustive_wait_more_than_60_handles. It creates 70 manual reset events, signals four of them spread across the list (indices 3, 17, 42 and 68, leaving index 0 unsignalled so the batched path is actually exercised), and checks that _exhaustive_wait returns exactly those four.

On the old code the filter kept the already signalled handles in the remaining list, so they were waited on again and the call returned [3, 17, 42, 68, 17, 42, 68]. It also dropped unsignalled handles that should have stayed in the list. The test is skipped off Windows, so the Windows CI job is what covers it.

I have made the requested changes; please review again

Thanks for making the requested changes!

@picnixz: please review the changes made to this pull request.

The Windows jobs went red on my previous push and I have just fixed the test that caused it. Two mistakes in it, both my own, the connection.py change is untouched:

• I called _exhaustive_wait(events, 0). With a zero timeout BatchedWaitForMultipleObjects reports a timeout before its worker threads have run, so _exhaustive_wait took the except TimeoutError: return [] path and the test saw []. It now passes a real timeout.
• I had signalled events [3, 17, 42, 68]. Since the batched wait reports only the lowest signalled handle of each 63 handle batch, whether the old code produced a wrong result depended on whether the second batch got to report before being cancelled, so the test could have passed against the unfixed code. Signalling event 0 pins the first reported index at 0, which makes i > res[0] & i not in res evaluate 0 not in res and discard every remaining handle, so the old behaviour is caught either way.

Sorry for the noise.

You need to sign the CLA as well