gh-116167：允许禁用 GIL

原文 ↗ Hacker News 讨论 ↗

变更范围 / 当前状态

  • 这项变更来自于让 GIL 变为可选的工作（PEP 703）。
  • 当前 PR 需要使用一个特殊标志编译 CPython，然后通过运行时开关禁用 GIL。
  • 这明确是一个早期、研究阶段的步骤：预期只对无线程程序可靠工作。
  • 在禁用 GIL 的情况下，asyncio 测试会失败；一些简单的多线程程序“看起来”能运行，但不能保证安全。

单线程 vs 多线程性能

  • 移除 GIL 使多线程 Python 能够实现真正的多核并行，这对高线程负载（例如 ML、研究）很有用。
  • 对于单线程代码，多位评论者提到由于额外锁开销会有性能 损失；PEP 703 引用了 5–15% 的减速。
  • 有人希望随着时间推移通过更多优化降低单线程 nogil 构建的开销。

Asyncio、线程与兼容性

  • 一些评论澄清：异步 I/O 和操作系统线程是不同的；当前的破坏主要出现在混合线程和协程的 asyncio 测试中。
  • 讨论中对于“任何带线程的代码”是否都会失效存在困惑；共识是：许多现有线程模式，尤其是涉及共享对象的模式，在这个版本中是不安全的。

当前线程的替代方案

  • multiprocessing 被广泛提及为 CPU 密集型任务的替代方案，但：
    • 在 Windows 和 macOS 上，由于缺少 fork / 使用 spawn，它会很慢且不方便。
    • 较大的内存占用和复杂的共享数据结构会让基于进程的并行变得痛苦。
  • 像 Ray 这样的库可以帮助实现多进程和共享内存，但它们也有各自的限制（例如，面向不可变数组的对象）。

生态系统与 C 扩展的影响

  • 大多数原生（C/C++）扩展在隐式上依赖 GIL 来保证线程安全（全局变量、未同步的 list 修改等）。
  • 计划是：如果某个扩展依赖 GIL，就保持启用；从长远来看，扩展必须更新为 nogil 安全，或者明确使用 GIL。

Python 与其他语言及类型系统

  • 一些评论者认为，如果你今天想要“Python + 类型 + 并发”，Go、Rust、C#、Kotlin、Julia、Nim 或 BEAM 语言可能是更好的选择。
  • 也有人反驳说，Python 的生态系统（NumPy、PyTorch、ML/DS 工具链）占据主导地位，而 nogil 加现代类型检查器（例如 mypy、pyright）使 Python 在很多场景下具有竞争力。
  • 关于 Python 的速度和类型模型与“现代”语言之间的争论仍在继续，同时也承认 Python 仍会更慢，但仍可以显著改进。