gh-136421: Fix crash when _datetime is been initialized in multiple sub-interpreters #136422
Conversation
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.
|
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 |
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.
Misc/NEWS.d/next/Core_and_Builtins/2025-07-08-23-00-58.gh-issue-136421.uzieFA.rst
Outdated
Show resolved
Hide resolved
…e-136421.uzieFA.rst Co-authored-by: Peter Bierma <zintensitydev@gmail.com>
|
An alternative would be to make |
|
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? |
|
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