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

В однопоточном async runtime блокирующая синхронная операция останавливает поток, на котором выполняются все задачи. Пока она не завершится, runtime не сможет опрашивать другие futures, поэтому задержка одной операции превращается в задержку всего набора задач.

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

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

Асинхронная модель появилась как способ обслуживать большое число операций ожидания без выделения отдельного системного потока под каждую операцию. Задача добровольно уступает выполнение, когда future возвращает Poll::Pending, поэтому один поток может поочерёдно продвигать множество задач.

Такой подход эффективен для сетевого ввода-вывода, таймеров и других операций, интегрированных с runtime. Он не делает обычные блокирующие вызовы асинхронными автоматически: вызов, который удерживает поток, нарушает предположение о кооперативной передаче управления.

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

Предположим, async-задача вызывает синхронное чтение файла, ожидание блокировки мьютекса или sleep операционной системы. Во время такого вызова поток не возвращается в runtime, поэтому он не может опросить futures других задач.

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

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

Async-задача выполняется внутри вызова poll. Пока poll не завершился, runtime считает, что поток занят текущей задачей. Обычный блокирующий вызов не возвращает управление через Poll::Pending, поэтому планировщик не получает возможности переключиться на другую задачу.

В однопоточном runtime это останавливает весь прогресс задач на данном runtime. В многопоточном runtime другие worker-потоки могут продолжить работу, однако блокировки уменьшают доступный параллелизм и способны вызвать starvation при достаточной нагрузке.

Типичные варианты решения:

использовать библиотеку с настоящим async API, который регистрирует ожидание в runtime;
перенести короткую или неизбежную блокировку в специальный пул blocking-задач;
выделить отдельный системный поток для длительной работы и обмениваться результатами через канал.

spawn_blocking не превращает операцию в неблокирующую: он лишь выполняет её вне основного пула async-задач. Количество таких потоков обычно ограничивается runtime, поскольку без ограничения большое число запросов может создать чрезмерную нагрузку на систему.

Минимальная иллюстрация для Tokio:

use std::time::Duration;

#[tokio::main(flavor = "current_thread")]
async fn main() {
    let blocking = tokio::spawn(async {
        std::thread::sleep(Duration::from_secs(1));
        println!("блокировка завершена");
    });

    let other = tokio::spawn(async {
        println!("другая задача ждёт poll");
    });

    let _ = tokio::join!(blocking, other);
}

В этом примере std::thread::sleep блокирует единственный worker-поток. Вторая задача сможет быть опрошена только после возвращения потока из блокирующего вызова; точный порядок печати не следует использовать как контракт планирования.

Есть важный компромисс: отдельный поток или blocking-пул сохраняет отзывчивость async-части, но добавляет переключения контекста, потребление памяти, конкуренцию за ресурсы и необходимость ограничивать параллелизм. Для длительных CPU-bound вычислений часто предпочтительнее отдельный пул CPU-задач, а не общий пул blocking-операций.

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

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

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

Выбрана async-версия клиента для обычного пути, а редкие операции без async API перенесены в ограниченный blocking-пул. Это сохранило отзывчивость быстрых маршрутов и не позволило потоку запросов породить неограниченное число блокирующих работ.

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

Вопрос: Достаточно ли заменить std::thread::sleep на async-функцию, чтобы операция перестала блокировать runtime?

Ответ: Нет. Само наличие async у функции ничего не гарантирует. Важно, чтобы внутри использовались неблокирующие примитивы, которые при ожидании возвращают управление runtime. Если async-функция внутри вызывает блокирующий системный API до ближайшей точки возврата, она по-прежнему блокирует worker-поток.
Вопрос: Почему добавление worker-потоков не является полноценным исправлением блокирующего вызова?

Ответ: В многопоточном runtime другие задачи могут продолжить выполнение на свободных worker-потоках, но каждый блокирующий вызов занимает один из них. При достаточном числе таких вызовов все worker-потоки окажутся заняты, и async-задачи снова перестанут своевременно продвигаться. Кроме того, увеличение числа потоков повышает расходы и не устраняет проблему ограниченной пропускной способности блокирующей зависимости.
Вопрос: Можно ли надёжно отменить уже начавшуюся blocking-задачу через отмену её async-обёртки?

Ответ: Обычно отмена async-обёртки прекращает ожидание результата, но не прерывает уже выполняющийся произвольный блокирующий вызов. Поток может продолжать работу до естественного завершения операции, поэтому необходимы тайм-ауты на уровне самой библиотеки, cooperative-флаг отмены или изолированный процесс, если требуется жёстко прерывать вычисление. Это особенно важно для операций, которые долго удерживают ресурсы или продолжают обращаться к внешней системе.