-
-
Notifications
You must be signed in to change notification settings - Fork 32.5k
gh-135427: Fix DeprecationWarning for os.fork when run in threads with -Werror #136796
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
base: main
Are you sure you want to change the base?
Conversation
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
Most changes to Python require a NEWS entry. Add one using the blurb_it web app or the blurb command-line tool. If this change has little impact on Python users, wait for a maintainer to apply the |
I have created a NEWS entry for this fix, but actually this change has indeed a little impact on Python users, so maybe |
…nto fix-issue-135427
Many tests are failing with a warning - as now the Many of the failing tests do not fail where one would expect to have more than one thread running. For example, in When printing there the number of threads using Therefore, we should find a way to suppress the warning of running a fork within a thread in all the tests that fail. Petr suggests to consider using the If anyone knows where this extra thread comes from, it will be appreciated if this is explained :-) |
That is ironically exactly why we have this warning - threads in a process can come from everywhere including external libraries outside of our control. I do think you're on the right track in terms of how to enable this to be something using |
…ead. Started to fix tests.
@@ -1182,6 +1182,7 @@ async def runner(): | |||
@support.requires_fork() | |||
class TestFork(unittest.IsolatedAsyncioTestCase): | |||
|
|||
@warnings_helper.ignore_warnings(category=DeprecationWarning) # gh-135427 |
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.
The whole class has fork tests, maybe add decorator to class itself?
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.
Yes. I am still learning... I tried to avoid putting decorator to the classes themselves, as I thought that it is more correct that if someone adds a new test, that developer should see the depracation warning.
But what you suggest will save many lines of code.
And also it seems that in some cases the test may run with forks or without them, so I am not sure that it is correct to decorate the functions themselves. For example, ProcessPoolExecutorTest
extends ExecutorTest
but also ThreadPoolExecutorTest
extends ExecutorTest
. So the tests in ExecutorTest
must be decorated only if it is extended by ProcessPoolExecutorTest
.
…ific decorator to ignore only the fork in thread deprecation warnings
@encukou, @gpshead - I am not sure, but maybe we should indeed create two PRs. The one that is here for I think that the differences between the two PRs will only be the change in What do you think? |
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.
Sorry for the delay!
Thank you for tackling this, and finding all the places that need the suppression! I think this looks good, just needs a bit of polish/simplification.
Misc/NEWS.d/next/Library/2025-07-19-11-53-19.gh-issue-135427.iJM_X2.rst
Outdated
Show resolved
Hide resolved
I think this should go in 3.15 only, and go through the full testing period. |
Co-authored-by: Petr Viktorin <encukou@gmail.com>
…JM_X2.rst Co-authored-by: Petr Viktorin <encukou@gmail.com>
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.
Thank you! This is looking good, but needs a bit more polish yet.
|
||
# Mypy symlinks (generated by Misc/mypy/make_symlinks.py) | ||
Misc/mypy/_colorize.py | ||
Misc/mypy/_pyrepl | ||
Misc/mypy/token.py |
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.
This doesn't look related to this PR. Could you revert this, and the removal of the files themselves?
# gh-135427 | ||
# In some of the tests, a forked child forks another child of itself. In that case, using | ||
# warnings_helper.ignore_warnings decorator does not actually ignore the warning from that | ||
# child of child, and a warnings_helper.ignore_warnings exception is raised. | ||
with warnings.catch_warnings(): | ||
warnings.filterwarnings('ignore', | ||
message=".*fork.*may lead to deadlocks in the child.*", | ||
category=DeprecationWarning) | ||
super().setUpClass() | ||
cls.pool = cls.Pool(4) |
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.
These setUp
methods should be able to use the context manager too. Or is there something I'm missing?
# gh-135427 | |
# In some of the tests, a forked child forks another child of itself. In that case, using | |
# warnings_helper.ignore_warnings decorator does not actually ignore the warning from that | |
# child of child, and a warnings_helper.ignore_warnings exception is raised. | |
with warnings.catch_warnings(): | |
warnings.filterwarnings('ignore', | |
message=".*fork.*may lead to deadlocks in the child.*", | |
category=DeprecationWarning) | |
super().setUpClass() | |
cls.pool = cls.Pool(4) | |
with warnings_helper.ignore_fork_in_thread_deprecation_warnings(): | |
super().setUpClass() | |
cls.pool = cls.Pool(4) |
The repeated comment could go in ignore_fork_in_thread_deprecation_warnings
's docstring.
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.
This file looks added by mistake.
🤖 New build scheduled with the buildbot fleet by @encukou for commit 8b699d8 🤖 Results will be shown at: https://buildbot.python.org/all/#/grid?branch=refs%2Fpull%2F136796%2Fmerge If you want to schedule another build, you need to add the 🔨 test-with-buildbots label again. |
This is a small fix as suggested in #135427 - using
PyErr_WriteUnraisable()
instead ofPyErr_Clear()
.The fix includes a test which checks that the
DeprecationWarning
is provided when usingfork
orforkpty
within a thread, also when running with-Werror
.@encukou