gh-137109: refactor warning about threads when forking #141438
+65
−43
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This splits the OS API specific functionality to get the number of threads out from the fallback Python method and warning raising code itself. This way the OS APIs can be queried before we've run `os.register_at_fork(after_in_parent=...)` registered functions which themselves may (re)start threads that would otherwise be detected. This is best effort. If the OS APIs are either unavailable or fail, the warning generating code still falls back to looking at the Python threading state after the CPython interpreter world has been restarted and the after_in_parent calls have been made. The common case for most Linux and macOS environments should work today. This also lines up with the existing TODO refactoring, we may choose to expose this API to get the number of OS threads in the `os` module in the future.
gpshead
commented
Nov 12, 2025
Comment on lines
+8631
to
+8632
| // Called before AfterFork_Parent in case those hooks start threads. | ||
| Py_ssize_t num_os_threads = get_number_of_os_threads(); |
Member
Author
There was a problem hiding this comment.
The other comment on the issue was if we should make this call right after BeforeFork but before the fork call itself. I don't think it makes a lot of difference. This in theory is slightly faster as it runs in parallel with the new child, but might have the downside that actual posix pthread_atfork C library call users could have their own parent callback start a thread from C which we're still missing?
3.13 has been in use for over a year now and that hasn't come up so I'm inclined to leave this on this side of the fork for now as the code is slightly simpler.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This splits the OS API specific functionality to get the number of threads out from the fallback Python method and warning raising code itself. This way the OS APIs can be queried before we've run
os.register_at_fork(after_in_parent=...)registered functions which themselves may (re)start threads that would otherwise be detected.This is best effort. If the OS APIs are either unavailable or fail, the warning generating code still falls back to looking at the Python threading state after the CPython interpreter world has been restarted and the after_in_parent calls have been made. The common case for most Linux and macOS environments should work today.
This also lines up with the existing TODO refactoring, we may choose to expose this API to get the number of OS threads in the
osmodule in the future.