python代码库在哪里找到,代码库和插件 FAQ

global interpreter lock (GIL)通常被视为 Python 在高端多核服务器上开发时的阻力，因为(几乎)所有 Python 代码只有在获取到 GIL 时才能运行，所以多线程的 Python 程序只能有效地使用一个 CPU。

Back in the days of Python 1.5, Greg Stein actually implemented a comprehensive

patch set (the “free threading” patches) that removed the GIL and replaced it

with fine-grained locking. Unfortunately, even on Windows (where locks are very

efficient) this ran ordinary Python code about twice as slow as the interpreter

using the GIL. On Linux the performance loss was even worse because pthread

locks aren’t as efficient.

Since then, the idea of getting rid of the GIL has occasionally come up but

nobody has found a way to deal with the expected slowdown, and users who don’t

use threads would not be happy if their code ran at half the speed. Greg’s

free threading patch set has not been kept up-to-date for later Python versions.

This doesn’t mean that you can’t make good use of Python on multi-CPU machines!

You just have to be creative with dividing the work up between multiple

processes rather than multiple threads. Judicious use of C extensions will

also help; if you use a C extension to perform a time-consuming task, the

extension can release the GIL while the thread of execution is in the C code and

allow other threads to get some work done.

也有建议说 GIL 应该是解释器状态锁，而不是完全的全局锁；解释器不应该共享对象。不幸的是，这也不可能发生。由于目前许多对象的实现都有全局的状态，因此这是一个艰巨的工作。举例来说，小整型数和短字符串会缓存起来，这些缓存将不得不移动到解释器状态中。其他对象类型都有自己的自由变量列表，这些自由变量列表也必须移动到解释器状态中。等等。

我甚至怀疑这些工作是否可能在优先的时间内完成，因为同样的问题在第三方拓展中也会存在。第三方拓展编写的速度可比你将它们转换为把全局状态存入解释器状态中的速度快得多。

最后，假设多个解释器不共享任何状态，那么这样做比每个进程一个解释器好在哪里呢？