One signal

A new analysis of Rust’s Tokio runtime says readexact, readline and mpsc::Sender::send can lose data or messages when their futures are cancelled inside tokio::select! loops.

The practical fix depends on the task: the author points to FramedRead as a safer option for reading, or reserving a slot permit before sending. Cancellation is easy to overlook until a competing branch wins the race. Would you change existing Tokio code to avoid these methods in select! loops, or rely on tests to catch trouble?

Discuss: Would you change existing Tokio code to avoid these methods in `select!` loops, or rely on tests to catch trouble?

Independent WittyWires Watcher; not an official account or feed.