内存分配器

这是隔离解释器工作中最敏感的部分之一。最简单的解决方案是将内部“小块”分配器的全局状态移动到 PyInterpreterState 中，就像我们对几乎所有其他运行时状态所做的那样。以下详细阐述了细节和原理。

CPython 提供了一个内存管理 C-API，具有 三个分配器域：“raw”、“mem” 和 “object”。每个域都提供了等效于 malloc()、calloc()、realloc() 和 free() 的功能。可以在运行时初始化期间为每个域设置自定义分配器，并且可以使用相同的 API 将当前分配器包装到一个钩子中（例如，stdlib tracemalloc 模块）。分配器目前是运行时全局的，由所有解释器共享。

“raw”分配器预计是线程安全的，并且默认为 glibc 的分配器（malloc() 等）。但是，“mem” 和 “object” 分配器预计不是线程安全的，并且目前可能依赖于 GIL 来确保线程安全。部分原因是两者默认的分配器，即 “pyobject”，不是线程安全的。这是因为该分配器所有状态都存储在 C 全局变量中。（参见 Objects/obmalloc.c。）

因此，我们回到了隔离运行时状态的问题。为了让解释器停止共享 GIL，必须解决分配器的线程安全问题。如果解释器继续共享分配器，那么我们需要其他方法来获得线程安全。否则，解释器必须停止共享分配器。在这两种情况下，都有许多可能的解决方案，每个解决方案都有潜在的缺点。

为了保持共享分配器，最简单的解决方案是在对 PyMem_Malloc()、PyObject_Malloc() 等中 “mem” 和 “object” 分配器的调用周围使用细粒度的运行时全局锁。这会影响性能，但有一些方法可以缓解这种情况（例如，仅在创建第一个子解释器后才开始锁定）。

保持共享分配器的另一种方法是要求 “mem” 和 “object” 分配器是线程安全的。这意味着我们必须使 pyobject 分配器实现线程安全。这甚至可能涉及使用可扩展分配器（如 mimalloc）重新实现它。潜在的缺点在于重新实现分配器的成本以及此类工作固有的缺陷风险。

无论如何，切换到要求线程安全分配器将影响任何嵌入 CPython 并当前设置了非线程安全分配器的人。我们需要考虑谁可能会受到影响以及如何减少任何负面影响（例如，添加一个基本的 C-API 来帮助使分配器线程安全）。

如果我们确实停止了解释器之间共享分配器，我们只需要对 “mem” 和 “object” 分配器这样做。我们可能还需要为某些运行时级别的使用保留一组完整的全局分配器。由于需要查找当前解释器，然后进行指针间接寻址以获取分配器，因此会产生一些性能损失。嵌入器可能还需要为每个解释器提供一个新的分配器上下文。从好的方面来说，分配器钩子（例如 tracemalloc）不会受到影响。

最终，我们将采用最简单的方案

• 将分配器保留在全局运行时状态中
• 要求它们是线程安全的
• 将默认对象分配器（也称为“小块”分配器）的状态移动到 PyInterpreterState 中

我们尝试了 一个粗略的实现，发现它相当简单，并且性能损失几乎为零。

PyInterpreterConfig.own_gil

如果为 true（1），则新解释器将拥有自己的“全局”解释器锁。这意味着新解释器可以在没有其他解释器干扰的情况下运行。这有效地释放了充分利用多核的限制。这是本 PEP 的根本目标。

如果为 false（0），则新解释器将使用主解释器的锁。这是 CPython 中的传统（3.12 之前的）行为，其中所有解释器共享一个 GIL。当使用仍依赖于 GIL 来确保线程安全的扩展模块时，共享 GIL 可能是可取的。

在 PyInterpreterConfig_INIT 中，这将为 true。在 PyInterpreterConfig_LEGACY_INIT 中，这将为 false。

此外，为了安全起见，目前我们不允许在运行时初始化期间设置了自定义分配器的情况下 own_gil 为 true。包装分配器，类似于 tracemalloc，仍然是可以的。

PyInterpreterConfig.strict_extensions_compat

PyInterpreterConfig.strict_extension_compat 基本上是“PyInterpreterState.strict_extension_compat”的初始值。

扩展模块兼容性

如 扩展模块 中所述，许多扩展模块可以在多个解释器（以及每个解释器 GIL 下）中正常工作，而无需任何更改。如果此类模块未明确指示支持，导入系统仍将失败。最初，不会有太多扩展模块这样做，因此这可能是造成挫败感的潜在来源。

我们将通过添加一个上下文管理器来临时禁用对多个解释器支持的检查来解决此问题：importlib.util.allow_all_extensions()。或多或少，它将修改当前的“PyInterpreterState.strict_extension_compat”值（例如，通过一个私有的 sys 函数）。

扩展模块线程安全

如果模块支持与多个解释器一起使用，则主要意味着即使这些解释器不共享 GIL，它也能正常工作。唯一需要注意的是，当模块链接到具有内部全局状态且不是线程安全的库时。（即使像用作临时缓冲区的静态局部变量这样无害的东西也可能是一个问题。）使用共享 GIL 时，该状态受到保护。如果没有，此类模块必须使用锁来包装对该状态的任何使用（例如，通过调用）。

目前尚不清楚 supports-multiple-interpreters 是否与 supports-per-interpreter-gil 足够等价，以至于我们可以避免任何特殊处理。这仍然是一个有意义的讨论和调查点。这两个概念之间的实际区别（在 Python 社区，例如 PyPI 中）尚未得到充分理解，无法解决这个问题。同样，也不清楚我们能做些什么来帮助扩展维护者缓解问题（假设确实存在问题）。

在此期间，我们必须假设差异足够大，以至于会导致足够多的扩展模块出现问题。我们将采用的解决方案是

• 添加一个 PyModuleDef 槽，指示扩展可以在每个解释器 GIL 下导入（即选择加入）
• 将该槽作为“兼容”扩展定义的一部分，如前所述

缺点是，即使该工作量很小，如果没有模块维护者付出额外努力，也没有一个扩展模块能够利用每个解释器 GIL。这加剧了扩展模块兼容性中描述的问题，并且适用相同的解决方法。理想情况下，我们会确定差异不足以造成影响。

如果我们最终确实需要在每个解释器 GIL 下导入时选择加入，并且稍后确定没有必要，那么我们可以在那时切换默认值，使旧的选择加入槽成为空操作，并添加一个新的 PyModuleDef 槽用于显式选择退出。事实上，从一开始就添加该选择退出槽是有意义的。

扩展模块

目前，到目前为止，Python 最常见的用法是让主解释器单独运行。此提案对该场景中的扩展模块没有影响。同样，无论好坏，使用现有的 Py_NewInterpreter() 创建的多个解释器下的行为都不会发生变化。

请记住，某些扩展在多个解释器中使用时会中断，因为它们在全局变量中保留了模块状态（或者由于链接库的内部状态）。它们可能会崩溃，或者更糟糕的是，出现不一致的行为。这是PEP 630 及其相关内容的动机之一，因此这不是新情况，也不是此提案的结果。

相反，当使用提议的 API创建多个解释器（并进行适当设置）时，不兼容扩展的行为将发生变化。在这种情况下，导入此类扩展将失败（在主解释器之外），如限制扩展模块中所述。对于已经在多个解释器中中断的扩展，这将是一项改进。

此外，一些扩展模块链接到具有线程不安全内部全局状态的库。（请参阅扩展模块线程安全性。）此类模块必须开始将对该状态的任何直接或间接使用包装到锁中。这是与其他也实现多阶段初始化并因此指示支持多个解释器（即隔离）的模块的关键区别。

现在我们来说明上面提到的兼容性中断。某些扩展在多个解释器（以及每个解释器 GIL）下是安全的，即使它们没有表明这一点。不幸的是，导入系统无法可靠地推断出此类扩展是安全的，因此导入它们仍将失败。这种情况在上面的扩展模块兼容性中进行了说明。

C-API 中公开的对象

C-API（包括有限的 API）公开了所有内置类型，包括内置异常以及内置单例。异常作为 PyObject * 公开，但其余部分作为静态值而不是指针公开。这是我们为每个解释器 GIL 必须解决的少数几个非平凡问题之一。

使用永生对象，这是一个无关紧要的问题。

整合的好处

合并全局变量有很多好处

• 大大减少了 C 全局变量的数量（C 代码的最佳实践）
• 此举将注意力吸引到不稳定或损坏的运行时状态
• 鼓励在如何使用运行时状态方面更加一致
• 更容易发现/识别 CPython 的运行时状态
• 更容易以一致的方式静态分配运行时状态
• 运行时状态的更好的内存局部性

此外，间接好处中列出的所有好处也适用于此，并且那里列出的相同项目也受益。

工作规模

要移动的全局变量的数量足够大，但大多数是 Python 对象，可以批量处理（例如 Py_IDENTIFIER）。在几乎所有情况下，将这些全局变量移动到解释器都是高度机械化的。这不需要聪明才智，而是需要有人投入时间。

要移动的状态

剩余的全局变量可以归类如下

• 全局对象
  • 静态类型（包括异常类型）
  • 非静态类型（包括堆类型、structseq 类型）
  • 单例（静态）
  • 单例（初始化一次）
  • 缓存对象
• 非对象
  • 初始化后不会（或不太可能）更改
  • 仅在主线程中使用
  • 延迟初始化
  • 预分配缓冲区
  • 状态

这些全局变量分散在核心运行时、内置模块和标准库扩展模块之间。

有关剩余全局变量的细分，请运行

./python Tools/c-analyzer/table-file.py Tools/c-analyzer/cpython/globals-to-fix.tsv

已完成的工作

如前所述，这项工作已经进行了很多年。以下是一些已经完成的事情

• 运行时初始化的清理（参见 PEP 432 / PEP 587）
• 扩展模块隔离机制（参见 PEP 384 / PEP 3121 / PEP 489）
• 许多内置模块的隔离
• 许多标准库扩展模块的隔离
• 添加了 _PyRuntimeState
• 不再使用 _Py_IDENTIFIER()
• 静态分配
  • 空字符串
  • 字符串字面量
  • 标识符
  • Latin-1 字符串
  • 长度为 1 的字节
  • 空元组

工具

如前所述，有一些工具可以帮助识别全局变量并对其进行推理。

• Tools/c-analyzer/cpython/globals-to-fix.tsv - 剩余全局变量的列表
• Tools/c-analyzer/c-analyzer.py
  • analyze - 识别所有全局变量
  • check - 如果有任何未被忽略的不受支持的全局变量，则失败
• Tools/c-analyzer/table-file.py - 总结已知的全局变量

此外，对不受支持的全局变量的检查已集成到 CI 中，以防止意外添加新的全局变量。

全局对象

可以在解释器之间（无需 GIL）安全共享的全局对象可以保留在 _PyRuntimeState 上。对象不仅必须有效地不可变（例如，单例、字符串），而且即使引用计数也不能改变才能保证安全。永生性 (PEP 683) 提供了这一点。（另一种选择是不共享任何对象，这会给解决方案增加很大的复杂性，特别是对于 公开在公共 C-API 中的对象。）

内置静态类型是将共享的全局对象的特殊情况。它们有效地不可变，除了一个部分：__subclasses__（也称为 tp_subclasses）。我们预计内置类型上的其他任何内容都不会改变，甚至 __dict__（也称为 tp_dict）的内容也不会改变。

__subclasses__ 用于内置类型将通过使其成为一个 getter 来处理，该 getter 在当前 PyInterpreterState 中查找该类型。