gh-120161: Fix a Crash in the _datetime Module by ericsnowcurrently · Pull Request #120182 · python/cpython

…nterp_count (gh-120529)

gh-120182 added new global state (interp_count), but didn't add thread-safety for it.  This change eliminates the possible race.

…s[i].interp_count (pythongh-120529)

pythongh-120182 added new global state (interp_count), but didn't add thread-safety for it.  This change eliminates the possible race.
(cherry picked from commit 2c66318)

Co-authored-by: Eric Snow <ericsnowcurrently@gmail.com>

…es[i].interp_count (gh-120657)

gh-120182 added new global state (interp_count), but didn't add thread-safety for it.  This change eliminates the possible race.

(cherry picked from commit 2c66318, AKA gh-120529)

Co-authored-by: Eric Snow <ericsnowcurrently@gmail.com>

In pythongh-120009 I used an atexit hook to finalize the _datetime module's static types at interpreter shutdown.  However, atexit hooks are executed very early in finalization, which is a problem in the few cases where a subclass of one of those static types is still alive until the final GC collection.  The static builtin types don't have this probably because they are finalized toward the end, after the final GC collection.  To avoid the problem for _datetime, I have applied a similar approach here.

Also, credit goes to @mgorny and @neonene for the new tests.

FYI, I would have liked to take a slightly cleaner approach with managed static types, but wanted to get a smaller fix in first for the sake of backporting.  I'll circle back to the cleaner approach with a future change on the main branch.

…s[i].interp_count (pythongh-120529)

pythongh-120182 added new global state (interp_count), but didn't add thread-safety for it.  This change eliminates the possible race.

In pythongh-120009 I used an atexit hook to finalize the _datetime module's static types at interpreter shutdown.  However, atexit hooks are executed very early in finalization, which is a problem in the few cases where a subclass of one of those static types is still alive until the final GC collection.  The static builtin types don't have this probably because they are finalized toward the end, after the final GC collection.  To avoid the problem for _datetime, I have applied a similar approach here.

Also, credit goes to @mgorny and @neonene for the new tests.

FYI, I would have liked to take a slightly cleaner approach with managed static types, but wanted to get a smaller fix in first for the sake of backporting.  I'll circle back to the cleaner approach with a future change on the main branch.

…s[i].interp_count (pythongh-120529)

pythongh-120182 added new global state (interp_count), but didn't add thread-safety for it.  This change eliminates the possible race.

In pythongh-120009 I used an atexit hook to finalize the _datetime module's static types at interpreter shutdown.  However, atexit hooks are executed very early in finalization, which is a problem in the few cases where a subclass of one of those static types is still alive until the final GC collection.  The static builtin types don't have this probably because they are finalized toward the end, after the final GC collection.  To avoid the problem for _datetime, I have applied a similar approach here.

Also, credit goes to @mgorny and @neonene for the new tests.

FYI, I would have liked to take a slightly cleaner approach with managed static types, but wanted to get a smaller fix in first for the sake of backporting.  I'll circle back to the cleaner approach with a future change on the main branch.

…s[i].interp_count (pythongh-120529)

pythongh-120182 added new global state (interp_count), but didn't add thread-safety for it.  This change eliminates the possible race.