喜闻乐见的去掉 GIL 的两篇文章

[est]

https://lwn.net/Articles/754577/

https://lwn.net/Articles/754162/

[kslr]

啊，这糟糕的 python 我已经自废右手换仿生 nodejs 了

[jimages]

所以就是雷声大雨点小。

[jimages]

想要去掉 GIL 而做到向下兼容是不可能的，只有再等 python4 了........

[Cbdy]

@jimages 搞不好 py4 又和 py3 不兼容，这就完彻了

[pathbox]

想去 没搞个大动静很难吧

[est]

@kslr nodejs 压根就不支持原生线程。GIL 也就无从谈起。
@Cbdy 文章里有写。python 3.8 计划搞一搞。2018 年 8 月发版。

[blackjar]

那么多解释器 换一个用啊 或者大佬自己写一个好了

[copie]

@jimages 不是说 Python 这门语言是不需要 GIL 的吗？
GIL 是 Python 解释器实现的锅，自认为没有兼容性问题。个人推测

[est]

@copie Python 标准里的确没有规定必须用 GIL。CPython 的 GIL 是绕不过去的。 然而大多数生态都是围绕 CPython 的。所以然并卵。除非你用纯 Py 不依赖任何第三方库。

[neoblackcap]

@est 其实按 GraalVM 的思路是可以的，Python 实际运行的是 GraalVM 的字节码，至于 C 扩展，编译成 LLVM IR，也是又 GraalVM 运行，这样就可以做到底层的都是字节码，而上层不变。

[est]

@neoblackcap 好像没那么简单。很多 C 扩展依赖特定的 ref counting 内存 allocate 机制。比如 numpy。

[neoblackcap]

@est 依赖特定实现的行为都是异端，哎~，这样的没法说。

[blless]

pypy 不是有一个无 GIL 版本？

[blless]

http://doc.pypy.org/en/latest/stm.html#what-pypy-stm-is-for

[RqPS6rhmP3Nyn3Tm]

一个古老的笑话
python 是一个双管猎枪，但是一次只能发射一颗子弹

[orangeade]

@kslr js 语法不更糟糕，还有弱类型，
性能这一块确实不行，毕竟没有大金主

[kslr]

@orangeade 那也比 python 半死不活的好

[qsnow6]

有协程就行了 GIL 没有去的必要

[Arnie97]

@orangeade 现在有编译到 JS 的语言试图弥补一部分坑，例如 TypeScript

[PythonAnswer]

还不如多花点精力提高解释器在其他方面的速度

[ericls]

@kslr what?

[copie]

@est 是我疏忽了 把 Python 的大特点忘了😣

[lrxiao]

Gilectomy 我记得是我上次翻 PyCon2015/16 看到了 然后查了下就一直没有更新了，作者也是个学生也没得到 CPython 支持 PyPy 不是筹钱搞了下

现在活了吗

[owenliang]

一个工具性质的语言，非得全能。

[diggerdu]

没必要，真要是运算密集，为什么不用 multiprocessing 呢

[eriale]

目前 python web 开发中，要么是 prefork 的方式，要么是 async 的模式，这两种应对现在流行的微服务都有问题。
前者可以有效利用多核，但是在发生远程调用会把当前 worker 卡住。
后者无法有效利用多核，而且还要有好用的 http/rpc 请求库，包括 requests 也是要在 3.0 版本才支持 async，总而言之，目前异步请求库还不成熟。
如果去掉了 GIL，那就可以用线程池的方式，每个请求使用不同的线程处理，这样既可以利用多核 cpu，也可以利用底层的线程调度机制在发生微服务请求时自动切换线程。

当然，我最疑惑的是老项目里的代码怎么办，以前写代码很少考虑线程安全问题，如果去掉 GIL，搞不好很多代码就有问题了，而且不光是自己写的代码，使用的很多第三方库估计也会有多线程问题。

[est]

@eriale 可以 prefork 出来多个 async 的 worker 进程。23333

[est]

@eriale 线程池其实做 IO 性能并不高。async 或者 gevent 可以轻松打到几千个协程，多线程就跪了。

一般线程池是用来做 accept() 解决高并发的。不过然并卵 Linux 内核的 epoll 在多核下有惊群问题。

[orangeade]

@kslr 算了吧，nodejs 不照样半死不活，js 专心写前端就好了

[lolizeppelin]

js 也好意思 233

其实现在多线程问题对 Python 也没那么重要
高并发肯定分布式 分布式肯定跨机器
都跨机器了 。干脆也就只看多进程写法就是

提升一下 Python 本身的性能比解决 gil 锁更有用

[est]

@lolizeppelin 其实我也这么觉得。如果用 C 写扩展可以自己管理线程，完全绕过 Cpython。

[laike9m]

向 Larry Hastings 致敬！
如果 BDFL 是他而不是 Guido，估计 Python 早就把这事搞定了

[jiang42]

相对于去掉 GIL，我觉得改善 startup time 和单核单线程性能会比较重要……

[XIVN1987]

@kslr
python 现在明明是如日中天，最火的时候

[linkermlin]

提升性能的话，Cython 编译提升的最多。

[tkmiles]

@est epoll 的多核惊群? 能具体一点吗？我怎么记得 epoll 中内核已经解决了惊群了

[est]

@tkmiles accept() 有惊群。https://idea.popcount.org/2017-02-20-epoll-is-fundamentally-broken-12/

Google 专门搞了个 SO_REUSEPORT。通过 hash 分配新连接。。

[tkmiles]

@est 好吧~~之前把 wait_queue 中的 exclusive 标志位和惊群给搞混了

[lolizeppelin]

惊群对 Python 这种慢玩意还不是什么问题
实在有影响可以抄 Nginx 的做法

[est]

@lolizeppelin 人艰不拆。

[bnm965321]

GIL 其实不是什么重要的事情