Skip to content

gh-145587: fix busy loop in multiprocessing.connection.wait on Windows#145597

Open
Shrey-N wants to merge 10 commits intopython:mainfrom
Shrey-N:145587
Open

gh-145587: fix busy loop in multiprocessing.connection.wait on Windows#145597
Shrey-N wants to merge 10 commits intopython:mainfrom
Shrey-N:145587

Conversation

@Shrey-N
Copy link
Contributor

@Shrey-N Shrey-N commented Mar 6, 2026

On Windows, multiprocessing.connection.wait returns immediately if the object_list is empty, regardless of the timeout.

This fix adds a check to make sure the function actually sleeps for the duration of the timeout, matching the Unix behavior and stopping the 100% CPU usage spike.

Verified locally:-

import time
from multiprocessing.connection import wait
start = time.time()
wait([], 1.0) # took 0s before, now takes 1
print(time.time() - start)

Fixes #145587

…Windows

Ensure wait() blocks for the specified timeout when object_list is empty, preventing 100% CPU usage. This aligns the Windows behavior with the Unix implementation.
@aisk
Copy link
Member

aisk commented Mar 8, 2026

I think we should add a test to check if wait returns just about the same time as the timeout parameter.

Shrey-N and others added 2 commits March 8, 2026 11:59
Co-authored-by: AN Long <aisk@users.noreply.github.com>
@chris-eibl chris-eibl self-requested a review March 8, 2026 07:34
@Shrey-N
Copy link
Contributor Author

Shrey-N commented Mar 8, 2026

I have removed the unnecessary line and added the test as requested @chris-eibl @aisk

@chris-eibl chris-eibl requested review from chris-eibl and removed request for chris-eibl March 8, 2026 07:59
Copy link
Member

@chris-eibl chris-eibl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please fix failing CI.

@Shrey-N
Copy link
Contributor Author

Shrey-N commented Mar 8, 2026

yup just did that @chris-eibl :)

@Shrey-N
Copy link
Contributor Author

Shrey-N commented Mar 8, 2026

@chris-eibl I believe the CI failure is an unrelated UnboundLocalError issue in the main branch. My tests are now passing. Could you please restart the checks, maybe that fixes it... Thank you for your patience :)

@chris-eibl chris-eibl self-requested a review March 8, 2026 08:53
Copy link
Member

@chris-eibl chris-eibl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @Shrey-N.

The failing test_ci_fuzz_stdlib

======================================================================
ERROR: test_ci_fuzz_stdlib (test.test_tools.test_compute_changes.TestProcessChangedFiles.test_ci_fuzz_stdlib) (p=PosixPath('Modules/tomllib'))
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/runner/work/cpython/cpython-ro-srcdir/Lib/test/test_tools/test_compute_changes.py", line 57, in test_ci_fuzz_stdlib
    result = process_changed_files({f})
                                    ^
UnboundLocalError: cannot access local variable 'f' where it is not associated with a value

seems uncorrelated to me as well and maybe relates to #145232 @StanFromIreland?

@StanFromIreland
Copy link
Member

Thanks, I'll look into it.

@Shrey-N
Copy link
Contributor Author

Shrey-N commented Mar 8, 2026

Why did it fail now 😭

@chris-eibl
Copy link
Member

There is Modules\tomllib in LIBRARY_FUZZER_PATHS, which doesn't exist, and I assume when iterating over the unordered frozenset, it can happen that this is the first element we get ...

@Shrey-N
Copy link
Contributor Author

Shrey-N commented Mar 8, 2026

Thank you for the explanation on the failure @chris-eibl! And thank you both for the approvals :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

multiprocessing.connection.wait high CPU load with empty object_list

4 participants