查看原文
其他

no-GIL Python,启动!

转自:OSC开源社区(ID:oschina2013)

CPython 核心开发者 Thomas Wouters 代表 Python 指导委员会宣布:正式接受 PEP 703 提案。

PEP 703(Making the Global Interpreter Lock Optional,让全局解释器锁成为可选),简称 no-GIL,也被称为自由线程 (free-threaded)。

根据提案的描述,CPython 的全局解释器锁 (GIL) 阻止了同时多线程执行代码,成为了在多核 CPU 上提高 Python 代码运行效率的一大障碍。PEP 703 提案建议向 CPython 添加构建配置 (--disable-gil),使其在没有全局解释器锁的情况下运行 Python 代码,并进行必要的更改以保证解释器线程安全。
Thomas Wouters 表示,Python 指导委员会当然很清楚 no-GIL 意味着什么,社区普遍也是秉承支持的态度,毕竟它为 Python 带来巨大好处。
但与此同时,委员会担心移除 GIL 会破坏目前的所有扩展模块,或者显着降低 CPython 的性能或可维护性。此外,第三方 PyPI 软件包生态系是 Python 的一大优势,与 C 语言库的紧密、高效集成则是 CPython 的优势之一。它们使得存在多种软件包选择成为可能,这是 Python 的独特卖点。
因此他们需要谨慎实现 no-GIL,避免破坏这些优势,或者导致其他开发者放弃数十年的软件包开发。
由于还没有实现 no-GIL,评估实际影响以及让第三方软件包适应新的自由线程的实用性是很困难的。尤其是与线程相关的问题的不可预测性更是让难度升级,因为有些问题只有在显着负载下才会暴露。
目前 Python 指导委员针对 no-GIL 的实现计划分成三个阶段:
  1. 实验阶段。通过提供 build-time 选项,让开发者在构建时选择启用自由线程 (free-threaded)。在此阶段对外明确告知是实验性的,不支持用于生产环境。

  2. 支持但不默认阶段。该阶段将在 API 和 ABI 变更充分解决,并且有足够的社区支持时开始启动。

  3. 默认阶段。此时默认启用自由线程(初期仍支持禁用),但此阶段确切的标准很难确定,目标是使开发者尽可能无缝且无痛地进行升级和兼容。

相关链接:https://discuss.python.org/t/pep-703-making-the-global-interpreter-lock-optional-in-cpython-acceptance/37075
推荐阅读  点击标题可跳转

1、用Python自动化操作PPT,看完这篇文章就够了!

2、10 亿泡汤!B站广州游戏研发工作室被爆解散

3、口型几乎完美、还能卡点,霉霉说地道中文的视频火了,背后 AI 工具原来是它

继续滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存