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

[est]

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

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

[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 人艰不拆。