Repository navigation
fix: lock the translator list when adding the local exception translator - #6208
Conversation
|
@YukaSadaoka I merged master and added a19ef4f to guard the new lock to free-threaded Python 3.14.0rc1 and newer. Older free-threaded builds use a nonrecursive mutex here, which can deadlock if an exception translator imports another pybind11 module. The guard preserves existing 3.13t behavior, including the original race, while fixing it on 3.14+. This keeps this PR moving without adding another 3.13t workaround (it'd be non-trivial); the intent is to formally drop 3.13t support before the next release. |
|
@YukaSadaoka I'm working on bit rot fixes (for some of the CI failures here) separately. I'll come back here after the fixes are merged. |
The bit rot fixes were merged with #6209, then the |
rwgk
left a comment
There was a problem hiding this comment.
Approving based on manual review and review with GPT-6.1-Sol ultra.
|
Thanks @rwgk! |
Description
Fixes #6207.
check_internals_local_exception_translator()reads and pushes ontointernals.registered_exception_translatorswithout holdingexception_translator_mutex. This PR adds the mutex underPy_GIL_DISABLEDas a fix.with_exception_translators()because that callsget_internals()which would run the hook again.__GLIBCXX__isn't defined. Hence, libstdc++ builds are unaffected.Test
test_local_translator_registration_vs_internals_fetchkeeps callingensure_internals()frompybind11_testson a thread while the main thread first-imports a new module,mod_concurrent_import.test_exceptions.pylocally with clang 19 + libc++ +-fsanitize=threadagainst a TSan-built free-threaded CPython 3.14.7.Suggested changelog entry: