Является ли concurrent.futures лекарством от GIL?

Нет, concurrent.futures почти не имеет никакого отношения к GIL.

Использование процессов вместо потоков - лекарство от GIL. (Конечно, как и все лекарства, у него есть побочные эффекты. Но оно работает.)

Модуль futures просто дает вам более простой способ планировать и ждать выполнения задач, чем использование threading или multiprocessing напрямую. И у него есть дополнительное преимущество, заключающееся в том, что вы можете переключаться между пулом потоков и пулом процессов (и, возможно, даже циклом гринлета или чем-то безумным, которое вы изобретаете и создаете) без изменения кода future. Итак, если вы не знаете, будут ли в вашем коде проблемы с GIL, вы можете создать его для использования потоков, а затем переключить его на использование процессов с однострочным изменением, что довольно приятно.

Но если вы используете ThreadPoolExecutor, у него будут те же проблемы с GIL, как если бы вы вручную создавали пул потоков, очередь задач и т. Д. С помощью threading и queue. Если вы используете ProcessPoolExecutor, это позволит избежать проблем с GIL таким же образом (и с теми же компромиссами), как если бы вы использовали multiprocessing вручную.

А пакет PyPI - это всего лишь простой бэкпорт модуля concurrent.futures от 3.2 до 2.x (и 3.0-3.1). (Это не волшебным образом дает вам новый и вроде бы улучшенный 3,2 GIL или более улучшенный 3,3 GIL, не говоря уже об удалении GIL.)

Мне, наверное, не стоило даже упоминать изменения GIL, потому что это, кажется, только добавило путаницы ... но теперь позвольте мне попытаться исправить это, ужасно упрощая.

Если у вас нет ничего, кроме работы, связанной с вводом-выводом, потоки - отличный способ добиться параллелизма до разумного предела. И 3.3 заставляет их работать еще лучше, но для большинства случаев 2.7 уже достаточно, а для большинства случаев, где это не так, 3.3 все еще недостаточно хорош. Если вы хотите обрабатывать 10000 одновременных клиентов, вы захотите использовать цикл событий (например, twisted, tornado, gevent, tulip и т. Д.) Вместо потоков.

Если у вас есть работа, связанная с процессором, потоки вообще не помогают распараллелить эту работу. Фактически, они только усугубляют ситуацию. 3.3 делает это наказание не таким серьезным, но это все же штраф, и вам все равно никогда не следует этого делать. Если вы хотите распараллелить работу ЦП, вы должны использовать процессы, а не потоки. Единственное преимущество 3.3 состоит в том, что futures немного проще в использовании, чем multiprocessing, и он встроен, и его не нужно устанавливать.

Я не хочу отговаривать вас от перехода на 3.3, потому что это лучшая реализация лучшего языка, чем 2.7. Но лучший параллелизм - не повод двигаться дальше.