gh-156070: Fix operator precedence in multiprocessing's batched Windows wait - #156071
gh-156070: Fix operator precedence in multiprocessing's batched Windows wait#156071ekanshul wants to merge 1 commit into
Conversation
…tched wait ``i > res[0] & i not in res`` parses as ``i > (res[0] & i) not in res`` because ``&`` binds tighter than comparisons, so the Windows >60-handle path of ``_exhaustive_wait`` kept the wrong handles. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
The following commit authors need to sign the Contributor License Agreement: |
picnixz
left a comment
picnixz
left a comment
There was a problem hiding this comment.
If possible add a regression test
| @@ -0,0 +1,3 @@ | |||
| Fix :func:`multiprocessing.connection.wait` on Windows with more than 60 | |||
| handles: the batched wait used ``&`` where ``and`` was meant when removing | |||
There was a problem hiding this comment.
Do not mention the & detail. It is an implementation detail.
|
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 |
2 participants
In the Windows branch of
multiprocessing.connection._exhaustive_wait()that handles more than 60 handles, the filterparses as
i > (res[0] & i) not in resbecause&binds tighter than the comparison operators, so signalled handles could stay in the list and unsignalled ones be dropped. Useand, as intended.&used instead ofandwhen filtering ready handles on Windows #156070