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
aisk
changed the title
ZeroIntensity
left a comment
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.
ZeroIntensity
left a comment
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.
…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? |
4 participants
_datetimein sub-interpreters in the same time may crash the process #136421