Storia della domanda
Il trait UnwindSafe è stato introdotto in Rust 1.9 insieme a std::panic::catch_unwind per affrontare le preoccupazioni riguardanti la sicurezza delle eccezioni ereditate da C++ e altri linguaggi con gestione delle eccezioni. In Rust, i panici attivano il ripristino dello stack che garantisce l'esecuzione delle implementazioni di Drop, ma questo non garantisce automaticamente che le strutture dati rimangano in stati coerenti se un panico interrompe un'operazione logica. Il trait è stato progettato per contrassegnare i tipi che tollerano di trovarsi in uno stato attivo oltre un confine catch_unwind senza rischiare comportamenti indefiniti o errori logici.
Il problema
Quando un riferimento mutabile (&mut T) attraversa un confine catch_unwind, e T contiene mutabilità interna (come RefCell o Cell), un panico può lasciare T in uno stato logicamente inconsistente. Ad esempio, se si verifica un panico tra RefCell::borrow_mut e l'abbandono implicito della guardia risultante RefMut, il conteggio interno dei prestiti di RefCell rimane incrementato. Dopo che catch_unwind cattura il panico e l'esecuzione riprende, RefCell appare prestato mutabilmente, ma la guardia che dovrebbe decrementare il conteggio è stata abbandonata durante il ripristino. Questo stato "avvelenato" costituisce una violazione della sicurezza delle eccezioni poiché le operazioni successive su RefCell causeranno un panico o si comporteranno in modo errato, corrompendo effettivamente lo stato del programma in un modo che il codice sicuro non può rilevare o recuperare.
La soluzione
UnwindSafe funge da trait marker conservativo: è implementato automaticamente per la maggior parte dei tipi ma esplicitamente escluso per &mut T e qualsiasi aggregato che lo contenga. Vietando a &mut T di implementare UnwindSafe, il sistema di tipi impedisce di passare riferimenti mutabili in catch_unwind a meno che il programmatore non li avvolga esplicitamente in AssertUnwindSafe. Questo wrapper è un contratto unsafe in cui il programmatore dichiara che il tipo avvolto manca di mutabilità interna o che ha verificato manualmente la sicurezza delle eccezioni. Questa scelta architettonica costringe un'esplicita opt-in a un modello potenzialmente pericoloso, garantendo che l'esposizione accidentale di uno stato mutabile e mutabile interno attraverso confini di panico sia catturata al momento della compilazione.
use std::panic::{catch_unwind, AssertUnwindSafe}; use std::cell::RefCell; fn main() { let shared = RefCell::new(vec![1, 2, 3]); // Questo fallisce nella compilazione perché &mut RefCell non è UnwindSafe: // let _ = catch_unwind(|| { // let mut borrow = shared.borrow_mut(); // borrow.push(4); // panic!("interrotto"); // }); // Opt-in esplicito con riconoscimento unsafe: let result = catch_unwind(AssertUnwindSafe(|| { let mut borrow = shared.borrow_mut(); borrow.push(4); panic!("interrotto"); })); // Dopo il panico, shared potrebbe trovarsi in uno stato di prestito non valido, // ma abbiamo riconosciuto esplicitamente questo rischio con AssertUnwindSafe. println!("Recuperato: {:?}", result.is_err()); }
Descrizione del problema
Un server HTTP ad alte prestazioni costruito con hyper deve isolare i panici nei gestori di richieste definiti dall'utente per impedire che una singola richiesta malformata termini l'intero processo. Il server mantiene un pool di connessioni utilizzando RefCell (per prestazioni a thread singolo) per tenere traccia delle connessioni attive al database per thread. L'architettura avvolge ogni gestore di richieste in catch_unwind per catturare i panici e registrarli in modo elegante. Durante i test di carico, il server incontra un panico in un gestore che tiene un prestito mutabile del RefCell del pool di connessioni. Quando catch_unwind cattura il panico, il flag di prestito interno del pool rimane impostato su "prestito mutabile" perché la guardia RefMut è stata abbandonata durante il ripristino senza eseguire la logica di decremento. Le richieste successive sullo stesso thread tentano di prendere in prestito il pool, innescando un panico a runtime a causa dello stato già prestato, schiantando effettivamente il thread e perdendo lo stato del pool.
Soluzione 1: Eliminare catch_unwind e consentire la terminazione del processo
Questo approccio rimuove completamente il problema della sicurezza delle eccezioni lasciando che il processo si arresti su ogni panico, accettando che la disponibilità sia secondaria rispetto alla correttezza in questo contesto specifico.
Pro: Elimina completamente le preoccupazioni sulla sicurezza delle eccezioni; nessun rischio di corruzione dello stato; semplice da implementare.
Contro: Inaccettabile per la disponibilità in produzione; una richiesta malevola o difettosa termina l'intero servizio; viola i requisiti di affidabilità.
Soluzione 2: Sostituire RefCell con Mutex e utilizzare il poisoning
Sostituisci il pool basato su RefCell con Mutex<Pool> e sfrutta il rilevamento del poisoning del mutex di Rust.
Pro: Mutex rileva i panici nei thread che detengono il lock e si marca come avvelenato, consentendo i successivi tentativi di lock di rilevare la corruzione tramite PoisonError; la libreria standard fornisce sicurezza integrata.
Contro: Mutex introduce un sovraccarico di sincronizzazione non necessario per esecutori async a thread singolo; richiede la ristrutturazione del pool di connessioni per essere Send; il poisoning richiede una logica di gestione esplicita per reinizializzare il pool.
Soluzione 3: Avvolgere i gestori in AssertUnwindSafe con validazione dello stato
Mantieni RefCell per le prestazioni ma avvolgi il gestore in AssertUnwindSafe e implementa una guardia di drop personalizzata che reimposta lo stato di RefCell se si verifica un panico.
Pro: Mantiene i benefici in termini di prestazioni di RefCell; consente l'isolamento dei panici; possibile implementare la logica di recupero.
Contro: Richiede codice unsafe per interagire con AssertUnwindSafe; estremamente difficile garantire la sicurezza delle eccezioni per tutti i percorsi di codice; facile perdere casi limite in cui lo stato rimane corrotto.
Soluzione scelta e ragionamento
Il team ha scelto Soluzione 2 (Mutex con poisoning) per il pool di connessioni condiviso, mentre ha utilizzato Soluzione 3 solo per i buffer temporanei specifici delle richieste che possono essere reinizializzati in modo banale. Il meccanismo di poisoning esplicito di Mutex fornisce un modo standardizzato e affidabile per rilevare la corruzione senza richiedere una revisione unsafe di ogni possibile punto di panico. Il lieve sovraccarico di prestazioni è stato accettato in cambio della garanzia di sicurezza.
Risultato
Il server isola con successo i panici nei gestori di richieste senza rischiare la corruzione dello stato. Quando un gestore genera un panico mentre detiene il lock del pool, il mutex è avvelenato e il server rileva questo al prossimo accesso, eliminando il pool corrotto specifico per il thread e generando uno nuovo. Questo assicura che non si verifichino comportamenti indefiniti e che il servizio rimanga disponibile anche con input avversi.
Perché catch_unwind richiede UnwindSafe anche se Rust esegue i distruttori durante i panici?
Molti candidati presumono che poiché le implementazioni di Drop vengono eseguite durante il ripristino, la sicurezza delle eccezioni sia garantita. Tuttavia, UnwindSafe affronta lo stato logico dei dati, non solo le perdite di risorse. Un panico può interrompere una sequenza di operazioni (come aggiornare un campo di lunghezza prima dei dati corrispondenti), lasciando un oggetto in uno stato temporaneamente incoerente. Il distruttore viene eseguito su questo stato rotto, potenzialmente propagando la corruzione. UnwindSafe garantisce che il tipo non possa essere rotto dall'interruzione (dati immutabili) o che il programmatore riconosca il rischio. Impedisce di riprendere l'esecuzione con oggetti che violano le proprie invarianti.
Qual è la differenza tra UnwindSafe e i trait auto Send/Sync?
Mentre Send e Sync sono anche trait auto, utilizzano un ragionamento positivo: &T è Send se T è Sync, e &mut T è Send se T è Send. UnwindSafe utilizza un ragionamento negativo: &mut T è mai UnwindSafe, indipendentemente da T. Inoltre, AssertUnwindSafe funge da via di fuga a livello di valore (simile a unsafe impl ma per valori specifici), mentre le violazioni di Send/Sync richiedono tipicamente unsafe impl a livello di tipo. UnwindSafe si accoppia anche con RefUnwindSafe per riferimenti condivisi, creando un sistema a due trait simile ma distinto da Send/Sync.
Come fa il flag di prestito di RefCell a creare insicurezza con i panici, e perché Mutex non ha gli stessi problemi UnwindSafe?
RefCell si basa su un flag di prestito runtime. Se si verifica un panico tra borrow_mut() e il Drop della guardia, il flag rimane impostato, ma la guardia è andata. Quando l'esecuzione riprende, RefCell appare prestato, ma non esiste alcun prestito effettivo. Questo è un errore logico che provoca futuri prestiti che mandano in panico erroneamente. Mutex evita questo implementando poisoning: se si verifica un panico mentre è mantenuto un lock, il Mutex si segna come avvelenato. Le chiamate lock() successive restituiscono un errore indicando che il thread precedente ha mandato in panico. Questo rende la corruzione esplicita e rilevabile, mentre la corruzione di RefCell è silenziosa. Pertanto, MutexGuard è effettivamente !UnwindSafe, ma il meccanismo di poisoning fornisce un percorso di recupero sicuro che RefCell non ha.