]> git.ipfire.org Git - thirdparty/Python/cpython.git/commit
[3.12] gh-105699: Use a _Py_hashtable_t for the PyModuleDef Cache (gh-106974) (gh...
authorEric Snow <ericsnowcurrently@gmail.com>
Fri, 28 Jul 2023 23:16:12 +0000 (17:16 -0600)
committerGitHub <noreply@github.com>
Fri, 28 Jul 2023 23:16:12 +0000 (23:16 +0000)
commitda151fdc7ac4a6d30740e4ef18071936a136790d
tree539f4fca2d647e02d9efeb9ddac8006c83c8f82a
parente5ca2aa2c6d86842183565606afcd0f85ed3eac9
[3.12] gh-105699: Use a _Py_hashtable_t for the PyModuleDef Cache (gh-106974) (gh-107412)

gh-105699: Use a _Py_hashtable_t for the PyModuleDef Cache (gh-106974)

This fixes a crasher due to a race condition, triggered infrequently when two isolated (own GIL) subinterpreters simultaneously initialize their sys or builtins modules.  The crash happened due the combination of the "detached" thread state we were using and the "last holder" logic we use for the GIL.  It turns out it's tricky to use the same thread state for different threads.  Who could have guessed?

We solve the problem by eliminating the one object we were still sharing between interpreters.  We replace it with a low-level hashtable, using the "raw" allocator to avoid tying it to the main interpreter.

We also remove the accommodations for "detached" thread states, which were a dubious idea to start with.

(cherry picked from commit 8ba4df91ae60833723d8d3b9afeb2b642f7176d5)
Doc/data/python3.12.abi
Include/internal/pycore_import.h
Include/internal/pycore_pystate.h
Include/internal/pycore_runtime_init.h
Python/import.c
Python/pystate.c