Categoria
Articoli tecnici organizzati per gruppo funzionale.
Invocare 'join_all' su una collezione di task propaga immediatamente il fallimento o panic del primo task difettoso, abbandonando l'attesa coordinata di tutte le altre future.
La chiamata a 'receiver.await' su un canale 'tokio::sync::oneshot' fallisce se il 'Sender' corrispondente viene deallocato prima di aver inviato un valore con 'send()'.
In un canale 'broadcast' a capacità limitata, se un ricevitore è troppo lento nell'elaborare i messaggi, i messaggi più vecchi vengono sovrascritti dal ring buffer provocando la restituzione dell'errore 'Lagged(count)'.
Tentare di inviare un messaggio tramite 'sender.send(msg).await' fallisce se l'estremità ricevente ('Receiver') del canale è stata chiusa o distrutta uscendo dallo scope.
Il panic si manifesta quando si invocano primitive I/O di Tokio (come Sleep, TcpStream, o Channel) all'interno di una normale funzione sincrona senza aver inizializzato il runtime con '#[tokio::main]'.
La funzione 'tokio::time::sleep()' accetta un limite massimo di durata temporale gestibile dalla ruota temporale dell'esecutore (circa 2 anni); passare 'Duration::MAX' solleva un panic immediato.
Le funzioni asincrone eseguite su un thread pool multi-thread (come 'tokio::spawn') richiedono che la Future risultante sia 'Send'; trattenere tipi non thread-safe (come 'Rc', 'RefCell' o 'std::sync::MutexGuard') tra due chiamate '.await' viola questo vincolo.
All'interno di 'tokio::select!', quando un ramo si completa, tutte le future degli altri rami vengono immediatamente abbandonate e distrutte (dropped); se una future non è cancel-safe (es. 'AsyncReadExt::read_exact'), i byte parzialmente letti dal socket vanno irrimediabilmente perduti.