gh-135427: Fix DeprecationWarning for os.fork when run in threads with -Werror #136796
Conversation
|
All commit authors signed the Contributor License Agreement. |
|
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.
The whole class has fork tests, maybe add decorator to class itself?
There was a problem hiding this comment.
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.
| @@ -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.
I still consider to create a dedicated ignore_fork_deprecated_warnings() decorator which will use
warnings.filterwarnings('ignore',
message=".*fork.*may lead to deadlocks in the child.*",
category=DeprecationWarning)This will prevent that in the future all the ignore_warning on DeprecatedWarning will not affect other deprecated warnings.
…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? |
This is a small fix as suggested in #135427 - using
PyErr_WriteUnraisable()instead ofPyErr_Clear().The fix includes a test which checks that the
DeprecationWarningis provided when usingforkorforkptywithin a thread, also when running with-Werror.@encukou