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

Многопоточный async runtime может переносить задачу между рабочими потоками при разных вызовах poll. Поэтому будущее, которое хранит состояние между точками await, должно быть Send. Если такое состояние содержит тип вроде Rc, будущее не удовлетворяет Send, и его нельзя безопасно передать другому потоку.

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

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

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

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

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

Неверное решение приводит не просто к потенциальной ошибке во время выполнения: компилятор отклоняет запуск такой задачи через API, требующий Future + Send. Это предотвращает скрытую передачу несинхронного состояния между потоками.

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

При компиляции async-функции Rust преобразует её в конечный автомат. В его вариантах хранятся локальные значения, необходимые после очередного await. Если значение уничтожено до await, оно обычно не входит в состояние будущего и не влияет на его Send.

В многопоточном runtime следующий вызов poll может выполнить другой рабочий поток. Поэтому всё состояние, сохраняемое между ожиданиями, должно быть переносимым. Send означает возможность передать владение значением другому потоку; Sync означает возможность безопасно разделять ссылки на значение между потоками. Для данного ограничения ключевым свойством является именно Send будущего.

Например, Rc не является Send, поскольку использует несинхронизированный счётчик ссылок:

use std::rc::Rc;

async fn operation() {}

async fn task() {
    let marker = Rc::new(());
    operation().await;
    drop(marker);
}

fn start() {
    tokio::spawn(task());
}

Вызов tokio::spawn требует, чтобы переданное будущее можно было перемещать между потоками. marker живёт через await, поэтому он становится частью будущего и делает всё будущее несоответствующим Send.

Исправления зависят от задачи. Можно заменить Rc на Arc, если состояние действительно должно совместно использоваться потоками, или уничтожить несинхронное значение до await. Если задача принципиально однопоточная, применяют локальный планировщик, например механизм spawn_local; при этом задача не переносится между потоками, но доступ к данным всё равно должен соответствовать правилам выбранной модели.

Ограничение не означает, что любой код внутри async-функции обязан использовать только Send-типы. Несинхронное значение допустимо, если оно не переживает точку await и потому не сохраняется в будущем. Кроме того, Send не делает совместный доступ безопасным: для разделяемого изменяемого состояния нужны подходящие примитивы синхронизации, например Mutex или каналы.

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

В HTTP-сервисе обработчик создавал локальный кэш на Rc<RefCell<_>>, затем ожидал ответ от базы данных и после этого продолжал обработку. При запуске обработчика как фоновой задачи многопоточного runtime компиляция завершилась ошибкой о несоответствии Send.

Рассматривались три варианта. Перенос всего сервиса на однопоточный runtime устранял требование миграции, но ограничивал использование ядер и был неоправдан для CPU-независимых запросов. Замена структур на Arc<Mutex<_>> сохраняла многопоточность, но добавляла синхронизацию и возможную конкуренцию за блокировку. Третий вариант состоял в том, чтобы не хранить кэш через await, а получить необходимые данные заранее или передать после ожидания только принадлежащий результат.

Выбрали третий вариант для этого обработчика: кэш не требовал совместного доступа и был нужен только до операции ожидания. Это устранило !Send-состояние без блокировок. Для действительно общего кэша применили бы Arc с подходящей синхронизацией, а не однопоточный runtime.

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

Вопрос: Достаточно ли заменить Rc на Arc, чтобы любая async-задача стала подходящей для многопоточного runtime?

Ответ: Нет. Arc решает только проблему переносимости счётчика ссылок. Содержащийся объект должен быть корректен при выбранном способе доступа: для совместного изменения обычно требуется Arc<Mutex<T>>, Arc<RwLock<T>> или другой потокобезопасный механизм. Кроме того, будущему могут не соответствовать Send другие сохранённые значения.

Вопрос: Почему несинхронное значение до await иногда не вызывает ошибку Send?

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

Вопрос: Чем запуск задачи в локальном планировщике отличается от исправления типа на Send?

Ответ: Локальный планировщик изменяет модель выполнения: задача остаётся привязанной к одному потоку и может хранить !Send-состояние. Замена типов на Send сохраняет возможность многопоточного планирования, но может потребовать атомарных операций, блокировок и более дорогого доступа к данным. Первый вариант подходит для состояния, которое по смыслу принадлежит одному потоку; второй — когда важны распределение нагрузки и совместное выполнение на разных потоках.