我刚刚在搜索这个新实现时发现,我使用的是Python 2.7,我必须安装这个,那么如果我使用它,我会忘记在CPython中的GIL吗?
concurrent.futures
几乎与全局解释器锁(GIL)无关。futures
模块只是提供了比直接使用 threading
或 multiprocessing
更简单的任务调度和等待方式。它还具有一个优点,你可以在不改变 future
代码的情况下在线程池和进程池之间切换(甚至可能是绿色线程循环,或者是你发明和构建的某些奇怪东西),这非常好。因此,如果你不知道你的代码是否会有GIL问题,你可以构建一个使用线程的代码,然后通过一行代码切换到使用进程,这相当不错。ThreadPoolExecutor
,它将有与手动使用 threading
和 queue
创建线程池、任务队列等完全相同的 GIL 问题。如果你使用 ProcessPoolExecutor
,它将以与手动使用 multiprocessing
相同的方式避免GIL问题(并具有相同的权衡)。concurrent.futures
模块从3.2回退到2.x (和3.0-3.1)的简单后移。它并不会自动给你提供新的,有点改进的3.2 GIL,或者更大的改进的 3.3 GIL,更不用说消除GIL问题了。twisted
,tornado
,gevent
,tulip
等),而不是线程。futures
比multiprocessing
更易于使用,并且已内置,而不需要安装它。concurrent.futures
除了让编写并发代码稍微简单一些之外,并没有解决任何问题。在3.2和3.3中对GIL的更改是完全独立的,这只是一个巧合,十多年来首次重大的GIL更改恰好出现在Python的同一版本中,即futures
库。 - abarnertpip-3.3 install passlib
,它正常工作。其次,在2.7上进行多进程处理的方式与3.3几乎完全相同。multiprocessing
模块在2.7和3.3之间几乎是相同的,而PyPI futures
回溯与3.3标准库中的concurrent.futures
几乎相同。 - abarnertpasslib
适用于3.3版本,那么你不需要等待。它已经适用于3.3版本了。 - abarnert
future
API的GreenThreadExecutor。(然而,这证明有点棘手,这就是为什么tulip
将为其协程事件循环带来略微不同的future
以供stdlib使用。) - abarnert