Python社区变天：可去除全局解释器锁GIL，真正多线程要来了

这次，Python 将不再是人们所说的伪多线程了。

• 长期来看（大约 5 年以上），no-GIL 构建应是唯一的构建；
• 我们希望非常谨慎地向后兼容。我们不希望出现另一个 Python 3 的情况，所有适应 no-GIL 构建所需的任何第三方代码更改应只适用于 with-GIL 构建（尽管仍要解决更老 Python 版本的向后兼容性问题）。这不适用于 Python 4。我们仍在考虑对这两个构建的 ABI 兼容性和其他细节的要求，以及对向后兼容性的影响；
• 在我们承诺完全转向 no-GIL 之前，需要看到社区的支持。我们不能只是更改默认设置，更希望社区弄清自己需要做什么工作来给予支持。我们核心开发团队需要获得新构建模式及相关所有内容的经验。我们要整理现有代码中的线程安全性，因而需要弄明白新的 C API 和 Python API。我们在获得这些洞见时还需要传达给 Python 社区的其他人，并确保自身想要做出的更改以及希望他们做出的更改是可取的；
• 在我们默认 no-GIL 设置之前的任何时候，如果事实证明了，它的破坏性太大导致收益太少，我们希望能够改变主意。这也就意味着我们会回滚所有工作，因此在我们确定要将 no-GIL 设为默认方式之前，特定于 no-GIL 的代码在某种程度上应是可识别的。

• 短期内，我们会将 no-GIL 构建作为一种实验性构建模式，大概是在 3.13 版本（也有可能推迟到 3.14 版本）。之所以是实验性的，是因为我们核心开发团队虽然支持这一构建模式，但不期望整个社区都会支持它。我们需要时间弄清自己要做什么，至少在 API 设计以及打包和分发方面，从而得到社区的支持。我们也不鼓励 distributor 将实验性 no-GIL 构建作为默认解释器发布。
• 中期来看，在我们确信得到足够的社区支持并使 no-GIL 的生产使用可行后，我们将支持 no-GIL 构建，但不是默认方式，而是在某个目标日期或某个 Python 版本中使它成为默认方式。具体的时间将取决于很多因素，比如 API 更改最终兼容性如何、社区认为他们仍然需要做多少工作等。我们预计这至少需要一至两年的时间。一旦我们宣布支持，预计将有一些 distributor 会开始默认发布 no-GIL。
• 长期来看，我们希望 no-GIL 成为默认方式，并删除 GIL 的所有痕迹（但不会不必要地破坏向后兼容性）。我们不希望等待太长时间，毕竟两种常用的构建模式同时存在会给社区造成很大的负担（比如需要双倍测试资源和 debug 场景）。但是我们也不能急于求成。我们认为这一过程将需要花费五年的时间。

© THE END 

转载请联系本公众号获得授权

投稿或寻求报道：[email protected]