-
-
Notifications
You must be signed in to change notification settings - Fork 31.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
gh-89240: Add _winapi.BatchedWaitForMultipleObjects and tests #107873
Conversation
I'm betting I'll need to regenerate some files, but besides that, this is ready for review and consideration for 3.13. @eryksun would appreciate you taking a look, though anyone's welcome. |
Co-authored-by: AN Long <aisk@users.noreply.github.com>
@@ -0,0 +1 @@ | |||
Allows :mod:`multiprocessing` to create pools of greater than 62 processes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should this say "on Windows" or does the "section" this news entry is in get communicated well in the ultimate generated NEWS? I'm used to just reading them as individual line items and not seeing the section header as that can be far away at times...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had to go and look, but it seems the sections tend to be short because we don't merge together all the prereleases. So chances are the heading will be visible at the same time as the entry is.
In general, we don't specify "Windows" in the NEWS entry when it's in that section, but it does tend to get called out in commit messages (this PR will get renamed on merge because I don't like the title anymore).
…s pools (pythonGH-107873) We add _winapi.BatchedWaitForMultipleObjects to wait for larger numbers of handles. This is an internal module, hence undocumented, and should be used with caution. Check the docstring for info before using BatchedWaitForMultipleObjects.
This doesn't actually resolve the original issue (I have another simpler PR for that), but I went to the trouble to build this functionality and it comes up fairly frequently, so figured I'd post it in case we want it anyway.Nope, we do need the whole thing. Update to this PR coming shortlyAdds
BatchedWaitForMultipleObjects
to wait for all the handles on their own threads (up to 3969 wait handles), and use the new function inmultiprocessing
to wait for the first handle before iterating through the whole pool.