摘要

正如指导委员会宣布的那样，PEP 703（使 CPython 中的全局解释器锁成为可选）的接受，描述了移除全局解释器锁工作的三个开发阶段。第一阶段始于 Python 3.13 开发的早期，包括提供自由线程（无 GIL）Python 构建，但明确表示其为“实验性”。第二阶段将使自由线程构建获得官方支持，但仍为可选；第三阶段将使自由线程构建成为默认。由于当时存在大量未知因素，进入下一阶段的标准当时被故意模糊化。本 PEP 旨在为进入第二阶段，使自由线程 Python 构建获得官方支持，建立明确的期望和要求。

动机

是否推进PEP 703（以及最终使其成为默认）的问题在于成本是否大于收益。使自由线程 Python 成为官方支持的构建至关重要，它标志着我们现在处于设计已定稿、API 可用且稳定、并且我们确信性能和复杂性成本并非高昂的阶段。

进入“官方支持”阶段是使自由线程 Python 成为默认构建，并最终成为唯一构建的重要一步。在我们决定准备好将其作为默认选项之前，我们需要更好地了解其成本和收益，而这只有当更多的 Python 生态系统开始支持自由线程 Python 时才能实现。目前，我们有足够的包和工具支持PEP 703，这清楚地表明我们走在正确的道路上，但还不足以做出最终决定。除了给 Python 社区时间进行必要的更改以支持自由线程 Python 之外，我们期望在第二阶段展示其在实际应用中的明显优势，并明确定义其在性能、支持负担和生态系统复杂性方面的成本。

基本原理

为了使 PEP 703 可接受，它应该具备吸引力、稳定性、可维护性、高性能（在 CPU 和内存方面），并且理想情况下，它应该具有稳定的 ABI，以便相同的轮子可以用于自由线程和带有 GIL 的构建。

• 吸引力：从各种实验中可以清楚地看出，自由线程 Python 具有巨大的潜在优势。它并非一个简单的即插即用解决方案——某些代码需要重新设计以充分利用新功能并避免性能陷阱——但当它被采纳时，它可以实现更高的性能、显著更低的延迟和新的基于线程的功能。
• 稳定性：大部分新 API 设计已在 3.13 中完成，并被成功用于支持许多第三方包中的自由线程 Python（例如参见https://py-free-threading.github.io/tracking/）。3.14 中还进行了一些开发，以增加更多便利功能，并替换以前依赖 GIL 实现线程安全的 API，但我们尚未不得不修改 3.13 中针对自由线程 Python 的 API。
• 可维护性：PEP 703 的大部分设计相对简单，大部分复杂性隐藏在 CPython 现有的 C API 之后。例如，无锁列表和字典 API（依赖 QSBR）以及避免死锁的关键区的实现细节可能复杂且难以正确实现，但它们为我们提供了易于使用且陷阱不多的 API。使更多 CPython 代码实现自由线程安全是一个相对简单的过程，尽管我们可能确实需要更多关于新 API 提供基本保证的文档（https://github.com/python/cpython/issues/128642）。
• 性能：根据 pyperformance 基准测试（例如由微软的 Faster CPython 团队或Meta 的 Python Runtime 团队运行），比较自由线程构建与带有 GIL 的构建，线性性能的损失目前约为 10%（macOS 上更接近 3%）。我们还有一些 PR 正在进行中，有望将 Linux 和 Windows 上的性能损失降至 10% 以下。
• 内存使用。由于 gc 模块实现不同，具体数字会有所差异，但目前自由线程 Python 的内存使用量约高出 15-20%（几何平均值，由 pyperformance 测量）。我们尚未花费大量时间尝试降低这一点，因此我们可能能够进一步降低。然而，实际情况是，更高的内存使用是实现高效、安全自由线程的代价，如果没有显著的性能损失，我们不太可能使其非常接近带有 GIL 的构建的内存使用量。
• 稳定 ABI。指导委员会提到稳定 ABI 支持可能是第二阶段的潜在要求。虽然拥有稳定 ABI 支持会使第三方包分发更容易，但这有点像“鸡生蛋，蛋生鸡”的问题：如果我们没有支持自由线程 Python 的包使用稳定 ABI，我们就不知道它是否足够好；如果我们发现问题，我们也无法从稳定 ABI 中删除它们。鉴于第二阶段旨在给社区时间来采用自由线程 Python 并就 API 和 ABI 提供反馈，我们不确定稳定 ABI 对于第二阶段应该有多强的要求。

规范

我们提议的使自由线程 Python 获得官方支持（第二阶段）的具体标准

• 可接受的性能。指导委员会曾表示，他们预计自由线程 Python 会慢 10-15%，但这并非硬性目标。我们目前约为 10%，预计不会变得更慢，但对于第二阶段（而非默认切换），我们提议将 15% 作为硬性性能目标。
• 可接受的内存使用。指导委员会未提及此点，也未见太多讨论。我们提议第二阶段的目标为 20%（几何平均值，由 pyperformance 测量）。对于第三阶段，我们需要社区的意见来确定内存和 CPU 性能之间的权衡应该在哪里。
• 经过验证、稳定的 API。这很难衡量，但我们看到现有 API 在自由线程 Python 中得到了广泛采用，并且我们无需对任何现有 API 进行根本性更改来适应它们。未来我们可能会为特定用例添加更多便利 API，但我们相信我们已经证明了现有 API 的可行性和稳定性。我们不需要在新 API 中进行破坏性更改，并且我们期望未来所有更改都遵循PEP 387 的更改策略。
• 内部文档。我们有多个核心开发人员致力于自由线程 Python，其中包括一些最近开始修复特定模块中的线程安全问题的人员，但我们可能需要加强自由线程 Python 内部的入门文档。这在 3.14 中应该不难实现。

满足这些标准后，我们相信 Python 3.14 是PEP 703 第二阶段的正确时间框架。

（请注意，这些只是进入第二阶段的**要求**。将自由线程 Python 设为默认（第三阶段）的决定截然不同，我们预计它将围绕社区支持、意愿以及展示明显优势。这留待未来的 PEP。）

未解决的问题

• 稳定 ABI 是否应成为自由线程构建“受支持”状态的强要求？

版权

本文档置于公共领域或 CC0-1.0-Universal 许可证下，以更宽松者为准。