内存分配器

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

CPython 提供了一个内存管理 C-API，具有三个分配器域：“raw”、“mem”和“object”。每个域都提供等效于 malloc()、calloc()、realloc() 和 free() 的功能。可以在运行时初始化期间设置每个域的自定义分配器，并且可以使用相同的 API 包装当前分配器以添加钩子（例如，标准库的 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，该状态受到保护。如果没有，此类模块必须使用锁包装对该状态的任何使用（例如通过调用）。

目前尚不清楚支持多解释器是否与支持每个解释器的 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 中查找该类型。