Historia pytania: Algorytm Drop Check (dropck) został wprowadzony, aby zamknąć lukę w poprawności w wczesnych wersjach Rust, gdzie ogólne destruktory mogły uzyskać dostęp do danych, które zostały już zwolnione. Przed dropck można było skonstruować strukturę trzymającą odniesienie do danych przydzielonych na stosie, zaimplementować Drop, aby je dereferować, a następnie trzymać odniesione dane przed zniszczeniem kontenera, co prowadziło do dostępu po zwolnieniu. Ten problem stał się krytyczny w przypadku ogólnych kolekcji, które mogły zawierać pożyczone dane, co wymagało konserwatywnej analizy w celu zapewnienia bezpieczeństwa destruktora.
Problem:
Gdy ogólny typ Container<T> implementuje Drop, kompilator musi zapewnić, że T żyje dłużej niż kontener, aby zapobiec dostępowi destruktora do nieprawidłowej pamięci. Dla typów korzystających z surowych wskaźników (np. *const T), kompilator nie ma informacji o czasach życia, ponieważ surowe wskaźniki nie są śledzone przez mechanizm pożyczek. Bez wyraźnych znaczników czasów życia kompilator nie jest w stanie zweryfikować, czy destruktor może dereferencjonować wskaźnik do danych należących do bieżącego zakresu, które mogłyby być zwolnione jako pierwsze.
Rozwiązanie:
PhantomData działa jako znacznik o zerowej wielkości, który symuluje właśność lub pożyczkę typu T lub czas życia 'a. Dodając PhantomData<&'a T> do struktury trzymającej surowy wskaźnik, informujesz kompilator, że struktura logicznie przechowuje odniesienie powiązane z czasem życia 'a. Algorytm Drop Check korzysta z tego, aby wymusić, że struktura nie może żyć dłużej niż 'a. Jeśli struktura implementuje Drop i teoretycznie mogłaby przeżyć swojego odniesienia, kompilacja kończy się niepowodzeniem, co zapobiega niezdefiniowanemu zachowaniu.
Budujesz parser protokołu sieciowego bez kopiowania, który opakowuje bufor bajtów. Definiujesz Packet<'a> zawierający surowy wskaźnik *const u8 do tymczasowego Vec<u8> odebranego z stosu sieciowego. Próbujesz zaimplementować Drop dla Packet, aby zaktualizować statystyki parsowania, przechodząc przez surowy wskaźnik. Niebezpieczeństwo polega na tym, że Vec<u8> jest zwolnione, gdy funkcja odbioru kończy działanie, ale Packet może być przechowywany w kolejce do późniejszego przetwarzania, co prowadzi do dostępu po zwolnieniu, gdy Drop jest wykonywane.
Po pierwsze, rozważasz użycie odniesienia &'a [u8] zamiast surowego wskaźnika. To korzysta z mechanizmu pożyczek, aby zapewnić, że bufor żyje wystarczająco długo. Jednak znacznie ogranicza to API, ponieważ nie możesz swobodnie przenosić pakietu ani przechowywać go w kolekcjach, które wymagają granic 'static, co uniemożliwia stosowanie wzorców samoodwołujących się, powszechnych w parserach.
Po drugie, rozważasz użycie Rc<Vec<u8>>, aby współdzielić własność bufora. To zapewnia, że dane pozostają ważne tak długo, jak istnieje jakikolwiek pakiet. Jednak wadą są koszty wydajności związane z liczeniem referencji i alokacją na stercie, co narusza wymagania zero-kopiowania i zerowego narzutu w przypadku przetwarzania sieciowego o dużej wydajności.
Po trzecie, rozważasz dodanie PhantomData<&'a ()>, aby oznaczyć zależność czas życia, jednocześnie zachowując surowy wskaźnik dla wydajności. Jednak ujawnia to, że implementacja Drop jest tutaj zasadniczo niebezpieczna, ponieważ kompilator nie może zagwarantować, że bufor przeżyje pakiet. Decydujesz się usunąć implementację Drop i zamiast tego użyć metody ręcznego czyszczenia wywoływanej przed zwolnieniem bufora lub przełączyć się na Cow<'a, [u8]>, aby obsługiwać zarówno pożyczone, jak i posiadane dane.
Wybierasz podejście Cow<'a, [u8]>, które eliminuje surowe wskaźniki i potrzebę niebezpiecznej logiki Drop. Efektem jest parser, który kompiluje się pomyślnie z surowymi gwarancjami czasów życia, zapewniając, że żaden pakiet nie może przeżyć swojego podłoża, jednocześnie utrzymując wydajność w przypadku danych pożyczonych.
Dlaczego kompilator pozwala na implementację Drop dla struktury zawierającej PhantomData<&'static T>, ale odrzuca to dla PhantomData<&'a T>, gdzie 'a jest nietrwałe?
Gdy czas życia jest 'static, dane, do których się odnosisz, żyją przez cały czas trwania programu, więc nie ma możliwości zwolnienia przed uruchomieniem destruktora. Gdy 'a jest lokalnym czasem życia, dane mogą być zwolnione, podczas gdy struktura nadal istnieje, co tworzy dostęp do zwisającego odniesienia w Drop. Kompilator odrzuca lokalny przypadek czasu życia, ponieważ nie może udowodnić, że destruktor nie uzyska dostępu do danych po ich zwolnieniu, podczas gdy 'static zapewnia tę gwarancję z założenia.
Jak PhantomData<T> (semantyka posiadania) różni się od PhantomData<&'a T> (semantyka pożyczania) w kontekście dropck, i dlaczego to pierwsze nie zapobiega ucieczce struktury ze swojego zakresu?
PhantomData<T> wskazuje, że struktura działa tak, jakby posiadała T, co wpływa na wariancję i kontrolę zwalniania, zakładając, że struktura może zwolnić T, ale nie wiąże czasu życia struktury z konkretnym pożyczonym czasem życia 'a. Dlatego kompilator zakłada, że struktura może przeżyć wszelkie lokalne dane, chyba że T sam zawiera czasy życia. W przeciwieństwie do tego, PhantomData<&'a T> w sposób wyraźny ogranicza strukturę do czasu życia 'a, zapewniając, że nie może ona przeżyć pożyczki, a tym samym zapobiegając dostępowi po zwolnieniu w destruktorach.
Jaki był cel atrybutu may_dangle (niestabilny/zdeprecjonowany) w odniesieniu do dropck i jak miał zastosowanie do typów takich jak Vec<T>?
Atrybut #[may_dangle] pozwalał na informowanie kompilatora, że implementacja Drop dla typu nie uzyska dostępu do zawartości ogólnego parametru T, nawet jeśli T nie przeżywałby ściśle kontenera. Było to kluczowe dla kolekcji takich jak Vec<T>, które posiadają swój bufor, ale nie muszą odczytywać wartości T podczas zwalniania (po prostu zwalniają pamięć). Kandydaci często przeoczają, że Drop Check jest domyślnie konserwatywne, zakładając, że Drop może uzyskać dostęp do wszystkiego, a may_dangle była mechanizmem umożliwiającym rezygnację z tego założenia dla elastyczności w kolekcjach, chociaż wymagało to niebezpiecznego kodu i ścisłych invariantów, aby zapobiec dostępowi do danych zwisających.