python gil 多核_Python全局解释器锁（GIL）在Linux上使用taskset解决多核系统问题？...

所以我刚刚看完了关于Python全局解释器锁(GIL)http://blip.tv/file/2232410的演讲。

其要点是GIL对于单核系统来说是一个非常好的设计(Python本质上把线程处理/调度留给了操作系统)。但这会严重影响多核系统，最终导致IO密集型线程被CPU密集型线程严重阻塞、上下文切换开销、ctrl-C问题[*]等等。

因此，既然GIL限制我们基本上在一个CPU上执行一个Python程序，我的想法是为什么不接受这一点，而只是在Linux上使用taskset将程序的关联性设置为系统上的某个core/CPU(特别是在多个Python应用程序在多核系统上运行的情况下)？

所以最终我的问题是：有没有人尝试过在Linux上使用taskset与Python应用程序(特别是在Linux系统上运行多个应用程序，以便多个核心可以与绑定到特定核心的一个或两个Python应用程序一起使用)如果有，结果如何？值得做吗？它是否会使某些工作负载的情况更糟？我计划这样做并测试它(基本上看这个程序是否需要更多或更少的时间来运行)，但我很想听听别人对你的经验。

加法：David Beazley(在链接视频中给出的那个家伙)指出，一些C/C++扩展手动释放吉尔锁，如果这些扩展被优化为多核(即科学或数值数据分析等)，那么，不是获得多核的好处来进行数字压缩，扩展将是实际上，它被限制在一个核心上(因此可能会大大减慢程序的速度)。另一方面，如果您不使用这样的扩展

我不使用多处理模块的原因是(在本例中)程序的一部分是严重的网络I/O绑定(HTTP请求)，因此拥有一个工作线程池是一个很好的方法来压缩性能，因为一个线程触发一个HTTP请求，然后因为它在等待I/O而放弃了GIL，另一个线程可以做到是这样的，所以程序的一部分可以很容易地运行100多个线程，而不会对CPU造成太大的伤害，让我实际使用可用的网络带宽。至于stackless Python/etc，我对重写程序或替换Python堆栈(可用性也是一个问题)并不太感兴趣。

[*]只有主线程可以接收信号，所以如果您发送ctrl-C，Python解释器基本上会尝试让主线程运行，以便它能够处理信号，但是由于它不直接控制运行哪个线程(这是留给操作系统的)，所以它基本上告诉操作系统继续切换线程，直到它最终到达主线(如果你不走运，可能需要一段时间)。