Uh oh!
There was an error while loading. Please reload this page.
gh-128384: Add locking to warnings.py. - #128386
Conversation
Expose the mutex from _warnings.c and hold it when mutating the filters list.
kumaraditya303
commented
Jan 1, 2025
I think the lock should be re-entrant, as locks are held when doing dict lookups which can call arbitrary python code. |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
…0xzwH.rst Co-authored-by: Kumar Aditya <kumaraditya@python.org>
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Co-authored-by: Kumar Aditya <kumaraditya@python.org>
kumaraditya303
commented
Jan 14, 2025
This looks good now from a brief look. |
The
warningsmodule has some (relatively minor) thread safety issues. Thecatch_warningscontex manager is a major issue but that will be handled in a different PR. There are races between updating thefilterslist and incrementing the_filters_versionnumber. Also, thewarn_explicit()uses the global state in a non-thread-safe way. These issues are relatively easy to fix with some extra locking.Changes:
_warningsmodule, as_acquire_lockand_release_lockDeprecatedTeststhat resulted in mixingpy_warningsandc_warningsmodules.The mutex used is non-reentrant and so some care is required to avoid deadlocks. I restructured the code in
warn_explicit()to reduce functions called within the locked section. Perhaps a re-entrant lock should be used instead?