Historia pytania
Cechę UnwindSafe wprowadzono w Rust 1.9 razem z std::panic::catch_unwind w celu rozwiązania problemów związanych z bezpieczeństwem wyjątków dziedziczonych z C++ i innych języków z obsługą wyjątków. W Rust, paniki wywołują rozwijanie stosu, które gwarantuje wykonanie implementacji Drop, ale nie zapewnia automatycznie, że struktury danych pozostają w spójnych stanach, jeśli panika przerywa logiczną operację. Cechę zaprojektowano w celu oznaczenia typów, które tolerują bycie w aktywnym stanie poza granicami catch_unwind bez ryzyka nieokreślonego zachowania lub błędów logicznych.
Problem
Gdy mutowalna referencja (&mut T) przekracza granicę catch_unwind, a T zawiera mutowalność wewnętrzną (taką jak RefCell lub Cell), panika może pozostawić T w logicznie niespójnym stanie. Na przykład, jeśli panika wystąpi między RefCell::borrow_mut a domyślnym zrzuceniem wynikowej strażnika RefMut, wewnętrzny licznik pożyczek RefCell pozostaje zwiększony. Po tym, jak catch_unwind przechwyci panikę i wykonanie się wznowi, RefCell wydaje się być mutowalnie pożyczony, ale strażnik, który mógłby zmniejszyć licznik, został zrzucony podczas rozwijania. Ten "strużony" stan stanowi naruszenie bezpieczeństwa wyjątków, ponieważ późniejsze operacje na RefCell spowodują panikę lub będą działać niepoprawnie, efektywnie psując stan programu w sposób, który bezpieczny kod nie może wykryć ani naprawić.
Rozwiązanie
UnwindSafe działa jako konserwatywna cecha znaczników: jest automatycznie implementowana dla większości typów, ale wyraźnie wyłączana dla &mut T i wszelkich struktur zawierających ją. Zakazując, aby &mut T implementowało UnwindSafe, system typów zapobiega przekazywaniu mutowalnych referencji do catch_unwind, chyba że programista wyraźnie opakuje je w AssertUnwindSafe. Ten opakowanie to niebezpieczny kontrakt, w którym programista twierdzi, że opakowany typ albo nie ma mutowalności wewnętrznej, albo że ręcznie zweryfikował bezpieczeństwo wyjątków. Ten wybór architektoniczny wymusza wyraźne opt-in do potencjalnie niebezpiecznego wzorca, zapewniając, że przypadkowe wystawienie mutowalnego, wewnętrznie mutowalnego stanu poza granice paniki jest uchwycone w czasie kompilacji.
use std::panic::{catch_unwind, AssertUnwindSafe}; use std::cell::RefCell; fn main() { let shared = RefCell::new(vec![1, 2, 3]); // To nie kompiluje się, ponieważ &mut RefCell nie jest UnwindSafe: // let _ = catch_unwind(|| { // let mut borrow = shared.borrow_mut(); // borrow.push(4); // panic!("przerwane"); // }); // Jawne opt-in z niebezpieczną zgodą: let result = catch_unwind(AssertUnwindSafe(|| { let mut borrow = shared.borrow_mut(); borrow.push(4); panic!("przerwane"); })); // Po panice, shared może być w nieprawidłowym stanie pożyczki, // ale wyraźnie uznaliśmy to ryzyko z AssertUnwindSafe. println!("Odzyskano: {:?}", result.is_err()); }
Opis problemu
Wydajny serwer HTTP zbudowany z hyper musi izolować paniki w definiowanych przez użytkownika obsługach żądań, aby zapobiec temu, że jedno wadliwe żądanie zakończy cały proces. Serwer utrzymuje pulę połączeń używając RefCell (dla wydajności jednowątkowej), aby śledzić aktywne połączenia z bazą danych na każdy wątek. Architektura owija każdą obsługę żądania w catch_unwind, aby przechwycić paniki i zarejestrować je w sposób płynny. Podczas testowania obciążenia, serwer napotyka panikę w obsłudze, która trzyma mutowalną pożyczkę puli RefCell. Gdy catch_unwind przechwytuje panikę, wewnętrzna flaga pożyczki puli pozostaje ustawiona na "mutowalnie pożyczoną", ponieważ strażnik RefMut został zrzucony podczas rozwijania bez wykonania logiki zmniejszania. Kolejne żądania w tym samym wątku próbują pożyczyć pulę, wyzwalając panikę w czasie wykonywania z powodu już pożyczonego stanu, skutecznie zawieszając wątek i tracąc stan puli.
Rozwiązanie 1: Wyeliminuj catch_unwind i pozwól na zakończenie procesu
Podejście to całkowicie usuwa problem bezpieczeństwa wyjątków, pozwalając na zrzut procesu w przypadku każdej paniki, akceptując, że dostępność jest drugorzędna wobec poprawności w tym konkretnym kontekście.
Zalety: Całkowicie eliminuje problemy z bezpieczeństwem wyjątków; brak ryzyka korupcji stanu; proste do wdrożenia.
Wady: Nieakceptowalne dla dostępności produkcji; jedno złośliwe lub błędne żądanie kończy całą usługę; narusza wymagania niezawodności.
Rozwiązanie 2: Zamień RefCell na Mutex i wykorzystaj zanieczyszczenie
Zamień pulę opartą na RefCell na Mutex<Pool> i wykorzystaj wykrywanie zanieczyszczenia w Mutexie Rust.
Zalety: Mutex wykrywa paniki w trzymających wątkach i oznacza się jako zanieczyszczony, pozwalając na późniejsze próby blokady wykryć korupcję za pomocą PoisonError; standardowa biblioteka zapewnia wbudowane bezpieczeństwo.
Wady: Mutex wprowadza nadmiar synchronizacji niepotrzebny dla jednowątkowych wykonawców asynchronicznych; wymaga przekształcenia puli połączeń w Send; zanieczyszczenie wymaga jawnej logiki obsługi dla ponownego inicjowania puli.
Rozwiązanie 3: Owinięcie obsług w AssertUnwindSafe z walidacją stanu
Zachowaj RefCell dla wydajności, ale owiń obsługę w AssertUnwindSafe i zaimplementuj niestandardowego strażnika zrzutu, który resetuje stan RefCell, jeśli wystąpi panika.
Zalety: Zachowuje korzyści wydajnościowe RefCell; pozwala na izolację paniki; można zaimplementować logikę odzyskiwania.
Wady: Wymaga niebezpiecznego kodu do interakcji z AssertUnwindSafe; niezwykle trudno jest zagwarantować bezpieczeństwo wyjątków dla wszystkich ścieżek kodu; łatwo przegapić przypadki brzegowe, gdzie stan pozostaje uszkodzony.
Wybór rozwiązania i uzasadnienie
Zespół wybrał Rozwiązanie 2 (Mutex z zanieczyszczeniem) dla współdzielonej puli połączeń, używając jednocześnie Rozwiązania 3 tylko dla specyficznych buforów czasowych, które mogą być łatwo ponownie zainicjowane. Jawny mechanizm zanieczyszczenia Mutex zapewnia wiarygodny, ustandaryzowany sposób wykrywania korupcji bez wymogu audytowania unsafe każdego możliwego punktu paniki. Minimalny narzut wydajnościowy został zaakceptowany w zamian za gwarancję bezpieczeństwa.
Wynik
Serwer skutecznie izoluje paniki w obsługach żądań bez ryzyka korupcji stanu. Gdy obsługa panikuje, trzymając blokadę puli, mutex staje się zanieczyszczony, a serwer wykrywa to przy następnym dostępie, porzucając uszkodzoną pulę lokalną wątku i uruchamiając nową. Zapewnia to, że nie występuje żadne nieokreślone zachowanie i że usługa pozostaje dostępna nawet przy wrogich danych wejściowych.
Dlaczego catch_unwind wymaga UnwindSafe, mimo że Rust wykonuje destruktory podczas panik?
Wielu kandydatów zakłada, że ponieważ implementacje Drop są wykonywane podczas rozwijania, bezpieczeństwo wyjątków jest zagwarantowane. Jednak UnwindSafe odnosi się do logicznego stanu danych, a nie tylko wycieków zasobów. Panika może przerwać sekwencję operacji (takich jak aktualizacja pola długości przed odpowiadającymi danymi), pozostawiając obiekt w tymczasowo niespójnym stanie. Destruktor działa na tym uszkodzonym stanie, potencjalnie propagując korupcję. UnwindSafe zapewnia, że typ nie może być uszkodzony przez przerwanie (niezmienne dane) lub że programista uznaje ryzyko. Zapobiega wznowieniu wykonania z obiektami, które naruszają swoje własne inwarianty.
Jaka jest różnica między UnwindSafe a auto-cechami Send/Sync?
Podczas gdy Send i Sync są również auto-cechami, korzystają z pozytywnego rozumowania: &T jest Send, jeśli T jest Sync, a &mut T jest Send, jeśli T jest Send. UnwindSafe korzysta z negatywnego rozumowania: &mut T jest nigdy UnwindSafe, niezależnie od tego, co zawiera T. Dodatkowo, AssertUnwindSafe działa jako wartość-kontrolna ucieczka (podobnie jak unsafe impl, ale dla określonych wartości), podczas gdy naruszenia Send/Sync zazwyczaj wymagają unsafe impl na poziomie typu. UnwindSafe łączy się również z RefUnwindSafe dla referencji współdzielonych, tworząc system dwucechowy podobny, ale odmienny od Send/Sync.
Jak flaga pożyczki RefCell tworzy niebezpieczeństwo z panikami, a dlaczego Mutex nie ma tych samych problemów UnwindSafe?
RefCell polega na flagach pożyczki w czasie wykonania. Jeśli panika wystąpi między borrow_mut() a Drop strażnika, flaga pozostaje ustawiona, ale strażnik znika. Gdy wykonywanie się wznowi, RefCell wydaje się być pożyczony, ale nie ma tak naprawdę żadnej pożyczki. To jest błąd logiczny, który powoduje, że przyszłe pożyczki panikują błędnie. Mutex unika tego, wdrażając zanieczyszczenie: jeśli panika wystąpi, gdy blokada jest trzymana, Mutex oznacza się jako zanieczyszczony. Kolejne próby lock() zwracają błąd, który wskazuje, że poprzedni wątek miał panikę. To czyni korupcję jawną i wykrywalną, podczas gdy korupcja RefCell jest cicha. Z tego powodu MutexGuard jest w rzeczywistości !UnwindSafe, ale mechanizm zanieczyszczenia zapewnia bezpieczną ścieżkę odzyskiwania, której RefCell nie ma.