自由线程 Python 的元年回顾
自由线程 Python 的元年回顾
发布于 2025 年 5 月 13 日
ngoldbaum
Nathan Goldbaum
上周，CPython 开发者发布了 CPython 3.14.0b1。本周，PyCon 2025 在宾夕法尼亚州匹兹堡拉开帷幕。这两个事件都标志着发布和稳定自由线程 Python 的工作取得了重大进展。
本文讲述了这项工作的元年故事，以及我们 Quansight 团队如何在支持实验性使用自由线程构建版方面发挥了关键作用，该构建版应用于依赖复杂依赖项集的实际生产工作流程。
引言：我们为何致力于为自由线程 Python 提供社区支持？
对自由线程 Python 的支持，释放了现代硬件（如今多核 CPU 和 GPU 已司空见惯）的全部计算能力。在启用 GIL 的构建版本中，要充分利用并行算法来挖掘 Python 中所有可用的计算资源，需要采取一些折衷方案和精心的调整。Python 的 threading 模块通常不被使用，因为 GIL 阻止了有效的并行扩展。相反，许多人会选择 multiprocessing，但是生成进程的开销很高，并且跨进程通信通常需要创建代价高昂的数据副本，而在多线程程序中，数据在线程之间隐式共享，这些副本是不必要的。
话虽如此，发布版本中包含编译代码的软件包无法直接支持自由线程构建。任何发布原生代码的软件包（许多 Python 软件包都这样做）都需要经过审核，以确保软件包能够构建，并且不会出现线程安全问题，这些问题在启用 GIL 的构建中是不可能发生的。
禁用 GIL 需要对 CPython 解释器进行深层次的结构性更改。同样，要完全支持现有软件包中的自由线程构建，也需要修复结构性问题，而直到现在，这些问题都算不上大问题。例如，为了方便或出于性能考虑，在 C 扩展的实现中使用全局状态不再安全，因为 GIL 不能防止 Python 同时访问全局状态，从而导致通过数据竞争产生未定义的行为。虽然即使使用带有 GIL 的 threading 模块也可能触发这样的线程安全问题，但在大多数情况下，GIL 阻止了这些问题的出现。自由线程构建使得修复这些问题变得更加紧迫。
主要成就
与 Meta 的 Python 运行时团队一起，我们为在大量软件包和项目中启用对自由线程 Python 的支持做出了重大贡献，包括：
- 打包和项目工作流程工具，例如 meson、meson-python、the setup-python GitHub Actions workflow、packaging、pip 和 setuptools。
- 绑定生成器，例如 Cython、pybind11、f2py 和 PyO3。
- PyData 生态系统中的基础软件包，例如 NumPy、SciPy、PyArrow、Matplotlib、pandas、scikit-learn 和 scikit-image。
- PyPI 下载量最高的依赖项，例如 Pillow、PyYAML、yarl、multidict 和 frozenlist。
我们目前还在研究尚未提供支持的常用软件包，包括 CFFI、cryptography、PyNaCl、aiohttp、SQLAlchemy 和 grpcio，以及用于机器学习工作流程的常用库，如 safetensors 和 tokenizers。
我们团队的 CPython 核心开发者还贡献了将在 CPython 3.14 中发布的多项重大改进：
- 在自由线程构建中，Python 的
warnings模块现在默认是线程安全的。可以通过配置选项或运行时命令行标志在启用 GIL 的构建中使其成为线程安全的。 asyncio中已经修复了大量的线程安全问题。我们的基准测试表明，使用带有线程池运行器的 asyncio 代码的并行扩展性得到了显着提高。- 对
ctypes模块进行了全面的线程安全改造。 - 自由线程垃圾收集器的性能得到了显着提升。
- 帮助实现了 3.14 中自由线程解释器使用的延迟引用计数方案。
- 为自适应专业化解释器实现了多个专业化，并支持发布优化，使自由线程 CPython 3.14 的单线程性能与启用 GIL 的构建非常接近。
- 大量的较小错误修复和线程安全改进。
我们还根据我们的经验编写了一份综合指南，用于在现有应用程序和软件包中支持自由线程 Python。我们希望我们编写的文档能够成为有价值的资源，以供人们在未来几年更新的“长尾”软件包，以支持自由线程 Python。
您还可以从 Meta 团队在 Meta 工程博客 上阅读有关这项工作的更多信息。
自由线程 Python 生态系统的现状如何？
去年这个时候，当 Python 3.13.0b1 发布时，更广泛的 Python 软件包生态系统或多或少在自由线程构建上完全崩溃。尝试使用 pip install 安装任何依赖项或仅纯 Python 依赖项的最简单软件包都可能导致构建错误。大多数这些问题不是由于根本问题引起的，而是由于不受支持的默认选项或在自由线程构建上破坏的次要假设引起的。
我们与软件包维护者和社区中的其他贡献者一起，已经解决了许多这些问题，并且今天的情况已经好多了。随着 Cython 3.1.0 的发布，该版本正式支持自由线程构建，我们还帮助修复了构建问题最重要的来源之一。
我们目前正在处理发布编译代码但仍未发布自由线程 wheels 的软件包。您可以使用我们手动更新的状态跟踪表 或使用 Hugo van Kemenade 的自动更新跟踪器跟踪我们的进度。
挑战
截至今天，自由线程 Python 构建已准备好进行实验。我们需要更多来自具有真实工作流程的人的关于性能不佳和错误的报告。可能的性能改进是巨大的，特别是在利用多处理并为此类方法的固有成本买单的工作流程中。但是，许多软件包仍然需要详细的审核才能发现线程安全问题。许多 Python 库都发布了可变数据结构，这些数据结构在共享突变下将无法正常工作，并且没有或只有最少的关于线程安全或多线程性能的文档。
正如影响整个编程语言包生态系统的这种规模的任何更改一样，我们遇到的情况是，流行的软件包没有处理支持自由线程所需的更改所需的资源。对于很少有人甚至没有人完全理解代码的大型遗留软件包而言，尤其如此。作为一个社区，我们需要了解依赖关系树中的这些问题，并努力实现对关键软件包的可持续维护。
你能如何提供帮助？
查看我们添加到主要自由线程指南中的贡献指南。我们正在跟踪生态系统范围的问题，并在 Quansight-Labs GitHub 组织上托管的 free-threaded-compatibility 存储库中编写自由线程指南的内容。
我们还帮助启动了一个社区 Discord 来主持关于支持自由线程构建的讨论。如果您有兴趣提供帮助，请加入我们！
来参加我们在 PyCon 的演讲！
我将与我的队友 Lysandros Nikolaou 在 PyCon 上发表演讲。如果您要参加会议，请来观看。我们将分享我们从移植软件包以支持自由线程构建的经验中的详细信息。我们希望 YouTube 上的录音将成为世界各地视觉学习者的持久宝贵资源。
我个人认为自由线程构建是该语言的未来，并且很高兴能够全职致力于实现这一目标。我也希望我们现在所做的工作能够在每天被数百万开发人员使用的长尾软件包中实现未来的工作，并显着提高语言的性能。
更多来自我们博客的文章
当你习惯于 pandas 或 Polars 时，掌握 DuckDB：第 2 部分
作者：Marco Gorelli
2025 年 3 月 25 日
Quansight Labs 2024 年度报告：关注和执行之年
作者：Pavithra Eswaramoorthy、Tania Allard、Irina Fumarel 和 Ralf Gommers
2025 年 3 月 19 日
我们的地址
connect@quansight.com 8656 W. Hwy 71, Bldg F200 Austin, Texas 78735
四处看看
问好
@2022 Quansight Inc. 保留所有权利。