вы, боюсь тоже ошибиться при работе
лучше в @rust_async спросить напрямую
Тут для всего есть отдельный чат?
все чаты перечислены в закрепе
Ну, если мы говорим про простые юнит-тесты, то это tokio::test. А если мы говорим про edge-cases, в которых можно поймать багу, то тут всё очень сложно. Самый простой способ не поймать баг — не использовать то, что может багнуться. Забудь про селекты, и дроп хендлов на футуры в экзекуторе. Прочитай https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/ Пиши код так, чтобы он выглядел как "structured concurrency". (К слову, для обычных тредов может быть полезно прочитать статью Кладова на эту тему: https://matklad.github.io/2019/08/23/join-your-threads.html) В общем, изучаешь best-practices и читаешь async vision, чтобы знать, где у асинка дыры. Проверять async код — это как проверять программы с goto; проще всего их проверять, когда у тебя нет ни одного goto в коде.
Общая идея-то мне понятна (с прерыванием потока исполнения) Пересмотрел пример и теперь не понимаю в чем там ошибка? Вот код async fn parse_line(socket: &TcpStream) -> Result<String, Error> { let len = socket.read_u32().await?; (1) let mut line = vec![0; len]; socket.read_exact(&mut line).await?; (2) let line = str::from_utf8(line)?; Ok(line) } В (2) считается же тот объём данных, что был доступен в (1), почему разрыв в строке получается? Много данных за раз считывается?
Видимо, с какого-то перепугу авейт на 2 пендится, с размером принимаемых данных как-то связано раз. Мол, где-то ещё есть ссылка на сокет, которая читает из tcpstream. Так предположил.
Нет, ты тоже не в ту сторону смотришь. У нас код выглядит как обычный растовый код, но на самом деле на любой await надо смотреть как на херню, у которой внутри panic при кенселе вызывается, а на любой селект надо смотреть как на catch_unwind, который ловит эти паники после кенсела.
Обсуждают сегодня