一个小白想法， Python 为什么不通过命令行开关切换两种 GIL 模式？

[O5oz6z3]

最近 python 出现一个惊艳的 no-gil 设计，想必大家已经知道了。

那么对于 python GIL 这个老问题，似乎常见的说法是：
粗粒度的 GIL 降低多线程的性能，细粒度的 GIL 降低单线程的性能。

那为什么不全都要，通过命令行开关切换两种 GIL 模式？
我本身并不太懂同步原语、线程安全、并行编程这些，所以想请教一下。欢迎指正！

[O5oz6z3]

@hsfzxjy #13
感觉“抽象泄露”有点像是“依赖副作用”，不知道算不算是“隐式依赖 GIL”？
看来 GIL 即使真的能去掉，距离正式使用也很漫长。

@sujin190 #16
因为我也不懂具体细节，所以还想着把 GIL 版本的初始化方法用的函数和数据结构复制修改成细粒度锁模式也许行得通。

[sujin190]

@O5oz6z3 #21 问题就在于解析器你能复制数据结构再搞一遍，但是那么多模块和扩展怎么办，你说的这种不仅有人想过还有人搞过，但是有个啥用，各种模块扩展都不兼容，那这样的 python 还有个啥用，现在 python 重要使用的场景中数学计算、web 、人工智能、爬虫，几乎都不受 GIL 影响，语言自身性能不高主要也不是 GIL 导致的，从这些来说搞掉 GIL 并不是一个十分重要的事情，从 Python 编译成执行的字节码来看，对比 GO 、Rust 这种的编译器优化水平，似乎 python 的编译器还是有改进的空间的，以及 jit 支持之类的显然收益更高吧

[O5oz6z3]

@sujin190 #22
明白了，比起对付 GIL ，还是先提升单线程的性能更划算。

[qdcanyun]

其实是有可能有的，Python Core Developer Łukasz Langa 最近写的 [Blog]( https://lukasz.langa.pl/5d044f91-49c1-4170-aed1-62b6763e6ad0/) 中记录了 Python 核心开发团队和 nogil 的作者 Sam Gross 沟通的一些内容，其中就有提到
> **Q: Is runtime enabling of nogil a long-term viable option or a transitional feature?**
> Ideally the end game is CPython without the GIL, period. However, there will be an expected long period of community adaptation. We want to avoid a rift similar to the Python 2 to Python 3 transition. Rather, we want the transition to be easier, even if that means stretching it over a longer period of time.

如果未来 nogil 能够 merge 进主干代码里，那么一开始势必会有一个 option 来让用户选择开关 GIL
至于为什么现在没有，其实可以看 Sam Gross 的那个文档，以及上面提到的 Blog ，去掉 GIL 不是简单的直接删掉 GIL 对象，涉及到 GC ，内存分配，以及不少基础库的改造

[lolizeppelin]

async 这么多年了都没把全部库搞定
gil 起码搞 10 年

[chinesehuazhou]

楼上 @qdcanyun 提到了核心开发跟 nogil 作者的对话。未来估计会出现这么个开关。对话全文我翻译出来了，贴个链接： https://mp.weixin.qq.com/s/SvUyyUGLZFbqEyERWWJIYQ

[O5oz6z3]

才发现好像在以前，GIL 默认就是多线程时才会主动开启？ docs.python.org/zh-cn/3/c-api/init.html#c.PyEval_InitThreads