Краткий ответ

Главный риск — взаимная блокировка: рабочий поток занят ожиданием, поэтому отправленная им зависимая задача не может начать выполнение. В результате первая задача не получает результат, а пул остаётся заблокированным.

Исторический контекст

Пулы потоков появились как способ повторно использовать ограниченное число потоков вместо создания нового потока для каждой операции. Это снижает накладные расходы и позволяет контролировать потребление ресурсов, но вводит очередь задач и зависимость между доступностью рабочих потоков и прогрессом вычислений.

Абстракция Future отделяет отправку работы от получения результата. Проблема возникает, когда получение результата выполняется синхронно внутри того же ограниченного пула, который должен выполнить ожидаемую задачу.

Постановка проблемы

Если единственный рабочий поток выполняет родительскую задачу и вызывает блокирующее ожидание её дочерней задачи, он перестаёт обрабатывать очередь. Дочерняя задача остаётся в очереди и не получает исполнителя.

Увеличение размера пула не является надёжным исправлением: если все рабочие потоки одновременно ждут задачи из того же пула, возникает тот же тупик. Дополнительный риск появляется при циклических зависимостях, когда задачи ждут результаты друг друга.

Подробное решение

ThreadPoolExecutor обычно помещает отправленную функцию в очередь, а свободный рабочий поток забирает её и выполняет. Вызов Future.result() без тайм-аута блокирует текущий поток до завершения соответствующей задачи.

В описанном сценарии поток уже занят родительской задачей. Дочерняя задача может быть поставлена в очередь, но свободного потока для неё нет. Поэтому это не проблема GIL: даже если дочерняя функция освободила бы GIL, ей всё равно нужен свободный рабочий поток.

Предпочтительный подход — не строить синхронное ожидание вложенной задачи внутри того же ограниченного пула. Зависимую работу можно выполнить последовательно в одном рабочем вызове, передать результат через координирующий код вне пула или использовать отдельный пул для независимого этапа.

from concurrent.futures import ThreadPoolExecutor

def load_data():
    return 21

def parent():
    value = load_data()  # зависимость выполняется в текущем worker-е
    return value * 2

with ThreadPoolExecutor(max_workers=1) as pool:
    print(pool.submit(parent).result())

Если вложенная задача действительно должна быть отдельной, число потоков должно учитывать максимальную глубину ожиданий, но это лишь снижает вероятность тупика, а не устраняет циклические зависимости. Тайм-аут у result() помогает обнаружить зависание и вернуть управление вызывающему коду, однако саму уже выполняющуюся родительскую задачу он автоматически не прерывает.

Ситуация из практики

В обработчике очереди задача загружает метаданные, отправляя отдельную подзадачу в тот же пул, а затем сразу вызывает result(). После ограничения пула одним потоком обработчики начали зависать: каждый занятый поток ждал работу, находившуюся в собственной очереди.

Рассматривались три варианта. Увеличить пул было быстро, но не гарантировало исправление при нескольких уровнях вложенности. Создать отдельный пул устраняло конкуренцию за worker-ы, но усложняло управление ресурсами и могло привести к чрезмерному числу потоков. Перенести зависимый вызов непосредственно в родительскую функцию оказалось проще и предсказуемее.

Выбрали третий вариант, а для внешних зависимостей добавили тайм-ауты и мониторинг длительности задач. После этого исчезли зависания, а число потоков осталось ограниченным.

Что кандидаты часто упускают

Всегда ли вложенное ожидание в том же пуле приводит к взаимной блокировке?

Нет. При наличии свободного потока зависимая задача может быть выполнена, пока другой поток ждёт её результат. Однако это требует достаточного запаса worker-ов и отсутствия циклических зависимостей, поэтому архитектурно полагаться только на увеличение размера пула рискованно.

Что изменится, если ожидание выполнять с тайм-аутом?

По истечении тайм-аута Future.result(timeout=...) возбуждает исключение тайм-аута у ожидающей задачи. Это освобождает её поток, но не гарантирует остановку зависимой задачи: если она уже выполняется, отмена обычно не прерывает её принудительно, а если она ещё в очереди, её можно попытаться отменить через Future.cancel().

Почему циклическая зависимость опаснее простой вложенной задачи?

При цикле каждая задача ждёт результат другой задачи, а ни одна из них не может завершиться первой. Даже большой пул не поможет, если все задачи цикла уже заняли worker-ы и синхронно ожидают друг друга. Такой граф зависимостей нужно разрывать изменением порядка вычислений, передачей промежуточных результатов или асинхронной координацией.