mirror of https://github.com/python/cpython.git
![]() Sharing mutable (or non-immortal) objects between interpreters is generally not safe. We can work around that but not easily. There are two restrictions that are critical for objects that break interpreter isolation. The first is that the object's state be guarded by a global lock. For now the GIL meets this requirement, but a granular global lock is needed once we have a per-interpreter GIL. The second restriction is that the object (and, for a container, its items) be deallocated/resized only when the interpreter in which it was allocated is the current one. This is because every interpreter has (or will have, see gh-101660) its own object allocator. Deallocating an object with a different allocator can cause crashes. The dict for the cache of module defs is completely internal, which simplifies what we have to do to meet those requirements. To do so, we do the following: * add a mechanism for re-using a temporary thread state tied to the main interpreter in an arbitrary thread * add _PyRuntime.imports.extensions.main_tstate` * add _PyThreadState_InitDetached() and _PyThreadState_ClearDetached() (pystate.c) * add _PyThreadState_BindDetached() and _PyThreadState_UnbindDetached() (pystate.c) * make sure the cache dict (_PyRuntime.imports.extensions.dict) and its items are all owned by the main interpreter) * add a placeholder using for a granular global lock Note that the cache is only used for legacy extension modules and not for multi-phase init modules. https://github.com/python/cpython/issues/100227 |
||
---|---|---|
.. | ||
cpython | ||
internal | ||
Python.h | ||
README.rst | ||
abstract.h | ||
bltinmodule.h | ||
boolobject.h | ||
bytearrayobject.h | ||
bytesobject.h | ||
ceval.h | ||
codecs.h | ||
compile.h | ||
complexobject.h | ||
datetime.h | ||
descrobject.h | ||
dictobject.h | ||
dynamic_annotations.h | ||
enumobject.h | ||
errcode.h | ||
exports.h | ||
fileobject.h | ||
fileutils.h | ||
floatobject.h | ||
frameobject.h | ||
genericaliasobject.h | ||
import.h | ||
intrcheck.h | ||
iterobject.h | ||
listobject.h | ||
longobject.h | ||
marshal.h | ||
memoryobject.h | ||
methodobject.h | ||
modsupport.h | ||
moduleobject.h | ||
object.h | ||
objimpl.h | ||
opcode.h | ||
osdefs.h | ||
osmodule.h | ||
patchlevel.h | ||
py_curses.h | ||
pybuffer.h | ||
pycapsule.h | ||
pydtrace.d | ||
pydtrace.h | ||
pyerrors.h | ||
pyexpat.h | ||
pyframe.h | ||
pyhash.h | ||
pylifecycle.h | ||
pymacconfig.h | ||
pymacro.h | ||
pymath.h | ||
pymem.h | ||
pyport.h | ||
pystate.h | ||
pystats.h | ||
pystrcmp.h | ||
pystrtod.h | ||
pythonrun.h | ||
pythread.h | ||
pytypedefs.h | ||
rangeobject.h | ||
setobject.h | ||
sliceobject.h | ||
structmember.h | ||
structseq.h | ||
sysmodule.h | ||
traceback.h | ||
tracemalloc.h | ||
tupleobject.h | ||
typeslots.h | ||
unicodeobject.h | ||
warnings.h | ||
weakrefobject.h |
README.rst
The Python C API ================ The C API is divided into these sections: 1. ``Include/``: Limited API 2. ``Include/cpython/``: CPython implementation details 3. ``Include/cpython/``, names with the ``PyUnstable_`` prefix: API that can change between minor releases 4. ``Include/internal/``, and any name with ``_`` prefix: The internal API Information on changing the C API is available `in the developer guide`_ .. _in the developer guide: https://devguide.python.org/c-api/