是merge.futures是GIL的药吗？

Question

我只是在寻找这个新的实现,我使用python 2.7,我必须安装它,所以如果我使用它,我会忘记CPython上的GIL这个词？

Answer 1

不,concurrent.futures几乎没有任何关于GIL的事情.

使用进程而不是线程是GIL的药物.(当然,像所有药物一样,它有副作用.但它有效.)

该futures模块只是为您提供了一种比使用threading或multiprocessing直接更简单的安排和等待任务的方法.它还有一个额外的好处,你可以在线程池和进程池之间交换(甚至可能是一个greenlet循环,或者你发明和构建的东西),而无需更改future代码.因此,如果您不知道您的代码是否会出现GIL问题,您可以构建它以使用线程,然后将其切换为使用具有单行更改的进程,这非常好.

但是,如果您使用ThreadPoolExecutor,它将具有完全相同的GIL问题,就像您使用threading和手动创建线程池,任务队列等一样queue.如果您使用ProcessPoolExecutor,它将以相同的方式(并具有相同的权衡)避免GIL问题,就像您multiprocessing手动使用一样.

PyPI包只是concurrent.futures3.2到2.x(和3.0-3.1)模块的简单反向端口.(它不会神奇地为您提供新的改进的3.2 GIL,或者更好的改进3.3 GIL,更不用说移除GIL了.)

我可能甚至不应该提到GIL的变化,因为这似乎只是增加了混乱......但现在,让我试着通过过度简化来理顺它.

如果你只有IO绑定工作,线程是获得并发的好方法,达到合理的限制.3.3确实让它们工作得更好 - 但是对于大多数情况来说,2.7已经足够好了,并且,对于大多数情况,它还不够,3.3仍然不够好.如果你要处理10000个并发客户端,你将要使用的事件循环(例如twisted,tornado,gevent,tulip,等),而不是线程.

如果您有任何CPU限制工作,线程根本无法帮助并行化该工作.事实上,他们使事情变得更糟.3.3使得惩罚不那么糟糕,但它仍然是一个惩罚,你仍然不应该这样做.如果要并行化CPU工作,则必须使用进程,而不是线程.3.3的唯一优点是futures比使用起来更容易multiprocessing,内置而不是需要安装它.

我不想阻止你转向3.3,因为它比2.7更好地实现了更好的语言.但更好的并发性并不是移动的理由.