Python GIL 真的是针对每个解释器的吗？
我经常看到人们谈论 GIL 是每个 Python 解释器的（甚至在 stackoverflow 上也是如此）。
但我在源代码中看到，GIL 似乎是一个全局变量，因此每个 python 进程中的所有解释器都有一个 GIL。我知道他们这样做是因为没有像 lua 或 TCL 那样传递解释器对象，只是一开始设计得不好。而且线程本地存储对于 python 人员来说似乎不可移植。
这是正确的吗？我简单浏览了一下我在项目中使用的 2.4 版本。
在以后的版本中，尤其是 3.0 中，这是否发生了变化？
I often see people talking that the GIL is per Python Interpreter (even here on stackoverflow).
But what I see in the source code it seems to be that the GIL is a global variable and therefore there is one GIL for all Interpreters in each python process. I know they did this because there is no interpreter object passed around like lua or TCL does, it was just not designed well in the beginning. And thread local storage seems to be not portable for the python guys to use.
Is this correct? I had a short look at the 2.4 version I'm using in a project here.
Had this changed in later versions, especially in 3.0?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
GIL 确实是针对每个进程的，而不是针对每个解释器的。这在 3.x 中没有改变。
The GIL is indeed per-process, not per-interpreter. This is unchanged in 3.x.
也许造成这种混乱的原因是大多数人认为 Python 每个进程都有一个解释器。我记得读到过，通过 C API 对多个解释器的支持很大程度上未经测试，而且几乎从未使用过。 （当我尝试时，没有正常工作。）
Perhaps the confusion comes about because most people assume Python has one interpreter per process. I recall reading that the support for multiple interpreters via the C API was largely untested and hardly ever used. (And when I gave it a go, didn't work properly.)
我相信（至少从 Python 2.6 开始）每个进程最多可以嵌入一个 CPython 解释器（其他运行时可能有不同的约束）。我不确定这是否是 GIL 本身的问题，但这可能是由于全局状态造成的，或者是为了防止第三方 C 模块中发生冲突的全局状态。来自 CPython API 文档：
您可能对 Unladen Swallow 项目感兴趣，该项目的最终目标是删除 GIL完全来自 CPython。其他 Python 运行时根本没有 GIL，例如（我相信）Stackless Python，当然还有< a href="http://www.jython.org/" rel="nofollow noreferrer">Jython。
另请注意，GIL 是 在 CPython 3.x 中仍然存在。
I believe it is true (at least as of Python 2.6) that each process may have at most one CPython interpreter embedded (other runtimes may have different constraints). I'm not sure if this is an issue with the GIL per se, but it is likely due to global state, or to protect from conflicting global state in third-party C modules. From the CPython API Docs:
You might be interested in the Unladen Swallow project, which aims eventually to remove the GIL entirely from CPython. Other Python runtimes don't have the GIL at all, like (I believe) Stackless Python, and certainly Jython.
Also note that the GIL is still present in CPython 3.x.