tokio::spawn(async {
let archived = tokio::spawn_blocking(|| тут архивация).await;
let saved_to_db = saved_to_db().await;
})

Хм... а это мысль. Спасибо!

Ага, понял! 👍

А есть ли какой-тo способ из tokio::io::BufReader записать всё в tokio::io::BufWriter?

tokio::io::copy ?

Ох, куда зарыли, под отдельную фичу.
Спасибо, похоже на оно.

косплеят стандартную библиотеку, там так же)

(std::io::copy)

а не эффективнее ли tokio::io::copy_buf из буферизированного читает?

кек, я не знал о таком, @someonetoignore ^

Похоже, оба подойдут, просто второй построже с границами.

Но спасибо, идею понял)

ну и второй потенциально более эффективный)

Всем доброго вечера.
Все никак не получается найти внятный ответ на один вопрос.

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

Чем это лучше или хуже чего-то вроде
trait Future<T> {
fn start(&mut self, cx: Context);
fn poll(&mut self) -> Poll<T>;
}
где start вызывается один раз до poll сохраняет единственный контекст, который используется при опросе до возврата Ready?

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

А чем тебе контекст мешает в poll?

Да собственно ничем. Просто интересная мотивация такого дизайна.

Я не писал хороший шедулер и не понимаю чем закрепление одного контекста за одной таской футуры может негативно сказаться на планировании.
Можно как-то мутировать закрепленный контекст.
И к тому же приходится учитывать, что пока футура в процессе опроса с новым контекстом, она может проснуться используя старый.

Может есть статьи или документация в одной из библиотек, подробно объясняющая как используется эта фича и какой от этого толк?

Я правильно понимаю, что в твоем варианте трейта Future метод start вызывается ровно один раз, и до вызовов метода poll?

Да, правильно

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

1. Метод start торчит пользователю. Мне, как пользователю, совсем не очевидно что я там должен писать когда пишу impl Future для своего типа.

2. Мне контекст вполне себе нужен и в poll если я хочу завейкать футуру не только при первом вызове.

То есть, я совсем не понимаю подоплёки по которой ты хочешь выносить это дело в отдельный метод start. И на первый взгляд это кажется лишним переусложнением.

1. poll конечно "прозрачнее" в плане своей сигнатуры, но не думаю что это тот треит, первостепенной задачей которого была простота.
2. Я вот их и не вейкал при вызове непосредственно. Только сохранял контекст и вейкал его асинхронно из другого места, потока. Притом из-за перезаписи приходится синхронизировать обращение к нему сохраненному, это муторно, сложнее и как-бы "дороже".
Могу предположить, что это полезно в самописной футуре, чтобы прервать футуру на половине работы и отдать поток шедулеру.

Да и даже если вейкать не только при первом вызове, футура может просто сохранить контекст в себе при старте и вейкать при любом опросе.

> синхронизировать обращение к нему сохраненному

Секундочку, а зачем? Если poll позвали с новым контекстом, то старый уже не нужен.