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]'.
TOKIO_NO_RUNTIME
→
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.
TOKIO_TIMER_OVERFLOW
→
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.
SEND_HELD_ACROSS_AWAIT
→
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.
SELECT_CANCEL_SAFETY
→
L'errore a tempo di compilazione impedisce il passaggio di tipi non thread-safe (come Rc o puntatori raw) tra thread diversi o attraverso chiamate 'tokio::spawn', richiedendo l'uso di equivalenti atomici come Arc.
E0277_SEND
→
L'errore compare quando si tenta di condividere un riferimento immutabile &T tra più thread simultaneamente senza che il tipo implementi il trait 'Sync', tipicamente risolvibile avvolgendo il tipo in un Mutex o RwLock.
E0277_SYNC
→
Il panic indica che un thread ha acquisito un Mutex della standard library e poi è andato in panic prima di rilasciarlo, avvelenando (poisoning) il lock per proteggere gli altri thread da dati potenzialmente corrotti.
MUTEX_POISONED
→
La barriera di sincronizzazione 'Barrier::new(n)' blocca tutti i thread chiamanti fino a quando esattamente 'n' thread non invocano 'barrier.wait()'; se uno dei thread termina precocemente o va in panic, tutti gli altri rimangono congelati per sempre.
BARRIER_DEADLOCK
→