Uh oh!
There was an error while loading. Please reload this page.
gh-136421: Fix crash when _datetime is been initialized in multiple sub-interpreters - #136422
gh-136421: Fix crash when _datetime is been initialized in multiple sub-interpreters#136422aisk wants to merge 5 commits into
Conversation
Uh oh!
There was an error while loading. Please reload this page.
ZeroIntensity
left a comment
There was a problem hiding this comment.
I think we need a more fundamental fix that prevents static types from being initialized concurrently. This is sort of a known issue, see #129817.
Uh oh!
There was an error while loading. Please reload this page.
A Python core developer has requested some changes be made to your pull request before we can consider merging it. If you could please address their requests along with any other requests in other reviews from core developers that would be appreciated. Once you have made the requested changes, please leave a comment on this pull request containing the phrase |
Uh oh!
There was an error while loading. Please reload this page.
ZeroIntensity
left a comment
There was a problem hiding this comment.
Please add a test. I'm still not fully convinced that this is the right approach; _PyStaticType_InitForExtension should be thread-safe on its own, or at least in the places where it's used.
I think the problem is that _datetime is special and has static types (because they need to be exposed via the capsule). Instead of initializing them in the module's execution function, let's do it during interpreter initialization in pycore_interp_init.
Uh oh!
There was an error while loading. Please reload this page.
…e-136421.uzieFA.rst Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
neonene
commented
Jul 12, 2025
An alternative would be to make |
aisk
commented
Jul 12, 2025
Due to issue #136423, importing _datetime into a sub-interpreter concurrently still results in a crash, even after this change, so it's hard to write a test. I also feel that this is not the correct way to fix the root cause, and this PR is more like a workaround. I'll continue to investigate #136423, as they appear to have the same root cause. Maybe we can find a better way to address them. So maybe we can wait sometime before continue this PR? |
ZeroIntensity
commented
Jul 12, 2025
I've put up #136583 as an alternative that avoids locking, at the cost of moving |
_datetimein sub-interpreters in the same time may crash the process #136421