а может быть такое, что при буфферизованном чтении файла и отправке прочитанных байт по grpc порядок получения этих байт меняется из-за async-кода?

вобщем, есть async метод, который читает файл в байтовый буффер и отправляет этот буффер по сети

может ли порядок отправки этих байт по сети меняться?

отправку делаю через mpsc::channel в tokio::spawn

Один файл и один получатель grpc? Не вижу что там может быть не так. Разве что grpc не гарантирует порядок доставки сообщений, но тут я не подскажу, не имел с ним дела.

понятно

есть сомнения, что последовательность отправки буфферов меняется

Файл читается через read? Количество прочитанных байтов учитывается при отправке?

да, через read; да учитывается

в цикле читается файл в буффер, пока read возвращает значение > 0

что дают async запросы, если для обработки данных все равно нужно сделать await?

не буду далеко ходить за примером и возьму teloxide

let response = client
        .post(&super::method_url(TELEGRAM_API_URL, token, method_name))
        .multipart(params)
        .send()
        .await
        .map_err(RequestError::NetworkError)?;

ничего не делают потому что пока футуру не awaitнуть она не будет исполняться

просто какая разница будет с blocking клиентом?

все равно нужно ждать, когда придут данные от I/O

пока ждешь что-то другое выполняется

"что-то другое" зависит от конфигурации tokio::main?

зависит от в целом от твоего кода

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

Стандартная конфигурация сервера: родительский поток и N потоков-исполнителей. Каждый запрос серверу направляется в один из потоков, дальше поток пакует его в футуру и время от времени поллит на предмет исполнения. Если уже исполнился - возвращает. Внутри футуры могут происходить аналогичные действия - пошли в базу, сделали запрос к другому сервису, etc - передали управление другому запросу на том же потоке. Таким образом засчёт передачи времени ожидания другим запросам, типичный асинхронный сервер может обрабатывать больше запросов, чем аналогичный по конфигурации или более сложный синхронный. Асинк легковеснее полноценных потоков/процессов, Асинк удобнее очередей.
Тут из контрпримеров разве что Elixir и его "миллионы" микропотоков, но там свои архитектурные особенности.

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