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.
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.
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
BatchedWaitForMultipleObjectsto wait for all the handles on their own threads (up to 3969 wait handles), and use the new function inmultiprocessingto wait for the first handle before iterating through the whole pool.