- 主题:各位大神：python能做到GIL锁真正去掉像C++一样支持多线程吗？
做不到，因为所有的第三方模块都假定存在 GIL，它们自己缺少必要的加锁。
去掉 GIL 之后，很多第三方模块都会跑飞掉。
Python 本身提供了好几种解决方案: multiprocessing 用于计算密集的，threading 用于 IO 密集的，以后还会提供子解释器，这个应该是最佳方案。
【 在 aiworking 的大作中提到: 】
: 小白请教一下
--
FROM 110.84.121.*
Python 是胶水语言，不可能做到所有模块纯 Python 的啊。
其实你需要的语言是 Java 哈哈。
Java 现在已经可以直接执行 .java 文件了。如果能再进一步，改成 Python 这种执行模式，那就是你想要的语言的了。
【 在 JulyClyde 的大作中提到: 】
: 如果所有模块都是：
: 1 纯python
: 2 RPC/IPC
: ...................
--
修改:hgoldfish FROM 110.84.121.*
FROM 110.84.121.*
multiprocessing 多进程时是可以跳过 GIL 的，都在不同的进程了。没问题的。
而子解释器底层是多线程，所以交换数据特别快。又每个线程都拥有自己的 GIL，所以仍然兼容以前的第三方模块，或者只需要少量改动。这个方案应该是最佳的。Python 目前已经完成了每个线程都拥有自己的 GIL 这个改造。创建多个子解释器的 API 也已经有了。现在还缺的是实现子解释器之间的极速对象传递。离最终完成已经不远了。
对比一下，go, java 都把协程和线程混合所以带来几个大的缺点：
1. 协程之间的通信仍然需要加锁。把协程的开销搞得很大，也容易出错。
2. 因为协程在线程间跳来跳去。所以用协程搞不了 GUI 开发。
3. 协程的实现特别复杂。需要对整个语言和周边的第三方模块进行全面的改造。
在 go, java 之外的其它语言就很烂了，像 c#, js 不客气地说就是一坨垃圾。现在的 Python 也是垃圾。不止使用会传染的 async/await 还在语言里面混入线程这种操作系统的概念，让程序员多了很多心智负担。
我认为安胖子是历史的罪人！全世界最烂的程序员！
唯一正确的答案就是 Python 的这个子解释器。如果 Python 能够快点出来，那么又一次走在世界的前面。期待 Python 废除 async/await，改回 gevent，再加个子解释器，无敌！
【 在 poggy 的大作中提到: 】
: >Python 本身提供了好几种解决方案: multiprocessing 用于计算密集的，threading 用于 IO 密集的，
: >以后还会提供子解释器，这个应该是最佳方案。
: 我说的就是这这些类， 它们只是多线程的外形， 因为GIL的存在， 运行时都不可能产生真正多线程时的竞合条件。
: ...................
--
修改:hgoldfish FROM 110.84.121.*
FROM 110.84.121.*
所以 Python 的 threading 模块是个败笔。
不如改用纤程实现。把当年 gevent 的 monkey patch 变成标准。
而且这也不太会破坏 Python 各种模块的兼容性。
【 在 poggy 的大作中提到: 】
: 解释器之间的极速对象传递。离最终完成已经不远了。
: 嗯， 多进程， 都在不同进程了， GIL自然不共享。
: 不过， 多线程， 实际上， multithread的多个实例， 都跑在同一个解释器下， 其实也都跑在同一个线程下面， 因此， 也就没有了多线程竞合。当然也有调度产生的执行序列被分片。但是， 线程锁已经不是实际意义的线程锁，因为都在一个线程里。
: ...................
--
FROM 110.84.121.*
有两个方案，一个是编译的时候能去掉 gil，但第三方模块都不支持。完全没有实用价值。
子解释器确实才是未来。
【 在 ensonmj 的大作中提到: 】
: 现在去掉gil就是基于子解释器的方案吧
--
FROM 110.84.121.*