async в трейтах и Pin

trait Repo {
    async fn get(&self, id: u64) -> Option<User>;
}

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 12, остальные разбираются в тренажёре.

1. #rs_async_traits1 / 5
   Зачем в асинхронном коде понадобился Pin?

   A)Чтобы закрепить задачу за конкретным воркером рантайма

   B)Чтобы запретить отмену задачи посреди выполнения

   C)Чтобы разместить future в куче и уменьшить размер стека

   D)Автомат future ссылается на свои поля — его нельзя двигать

   показать ответ и разбор

   +D)Автомат future ссылается на свои поля — его нельзя двигать

   // разбор: После разрезания async fn локальная переменная и ссылка на неё оказываются полями одной структуры. Перемещение такого значения сделало бы внутреннюю ссылку висячей, поэтому poll принимает Pin<&mut Self> — обещание, что значение больше не сдвинется. Отсюда tokio::pin! и Box::pin в местах, где future нужно удержать на месте.

2. #rs_async_traits2 / 5
   Компилятор требует, чтобы future был Send. Откуда берётся это требование?

   A)Многопоточный рантайм переносит задачи между воркерами

   B)Этого требует трейт Future в стандартной библиотеке

   C)Send нужен значению, живущему дольше одной функции

   D)Send добавляется макросом tokio::main ко всем типам

   показать ответ и разбор

   +A)Многопоточный рантайм переносит задачи между воркерами

   // разбор: Задача, начатая на одном воркере, может продолжиться на другом, поэтому её состояние обязано быть Send — а состояние включает всё, что живёт через await. Типовая причина ошибки — Rc или MutexGuard, удержанные через точку ожидания. Лечится сужением области жизни значения или переходом на current_thread.

3. #rs_async_traits3 / 5
   Какой тип на самом деле возвращает async fn f() -> u32?

   A)u32, обёрнутый в Poll

   B)Непоименованный тип, реализующий Future<Output = u32>

   C)Готовое значение u32: тип не меняется, меняется способ вызова

   D)Pin<Box<dyn Future<Output = u32>>> — рантайм требует боксирования

   показать ответ и разбор

   +B)Непоименованный тип, реализующий Future<Output = u32>

   // разбор: Компилятор строит анонимную структуру-автомат и объявляет для неё реализацию Future. Именно поэтому у такой функции нельзя записать тип возврата явно, а в трейтах она долго не поддерживалась. Box появляется только там, где future нужно спрятать за трейт-объектом.

4. #rs_async_traits4 / 5
   Что стоит за записью async fn в трейте с точки зрения типов?

   A)Метод возвращает Box<dyn Future>, который компилятор добавляет неявно

   B)Метод превращается в обычный, а ожидание разворачивается на стороне вызывающего

   C)Метод помечается атрибутом, и рантайм подставляет свою реализацию при вызове

   D)Метод возвращает скрытый ассоциированный тип, реализующий Future

   показать ответ и разбор

   +D)Метод возвращает скрытый ассоциированный тип, реализующий Future

   // разбор: Компилятор разворачивает async fn в трейте в метод, возвращающий impl Future, а под ним — скрытый ассоциированный тип у каждой реализации. Поэтому аллокаций нет и вызов статический. Обратная сторона в том, что у каждой реализации тип свой и неизвестного размера: трейт с таким методом не dyn-совместим, и в Box<dyn Trait> его не положить.

5. #rs_async_traits5 / 5
   Компилятор ругается, что future не Send из-за Rc внутри асинхронной функции. Какие есть выходы?

   A)Обернуть Rc в Mutex: блокировка сделает его пригодным для передачи между воркерами

   B)Заменить Rc на Arc либо сузить его область жизни так, чтобы он не пересекал точку ожидания

   C)Пометить функцию unsafe: это снимает проверку авто-трейтов для её состояния

   D)Перенести Rc в отдельную задачу и обращаться к нему через канал сообщений между ними

   показать ответ и разбор

   +B)Заменить Rc на Arc либо сузить его область жизни так, чтобы он не пересекал точку ожидания

   // разбор: В состояние задачи попадает всё, что живёт через await, поэтому Rc, созданный и уничтоженный между двумя точками ожидания, проблемой не является — часто достаточно передвинуть его или обернуть кусок в блок. Если значение должно жить через ожидание, берут Arc. Мьютекс здесь не спасает: неатомарным остаётся сам счётчик ссылок Rc.