Odpowiedź na pytanie
Gdy asynchroniczna przyszłość jest porzucana, podczas gdy jest zawieszona w punkcie oczekiwania (np. gdy ukończona zostaje siostrzana gałąź w tokio::select!), jej implementacja Drop jest uruchamiana synchronicznie w celu zniszczenia zajętych zasobów. Zagrożenie pojawia się, gdy przyszłość posiada zasoby wymagające asynchronicznego czyszczenia - takie jak opróżnianie TcpStream, wysyłanie ramki zamykającej protokołu lub zatwierdzanie transakcji w bazie danych - ponieważ trait Drop nie zapewnia kontekstu asynchronicznego. Jeśli przyszłość zostanie anulowana po częściowej modyfikacji stanu (np. zapisaniu połowy bufora pliku), ale przed finalizacją, synchroniczne Drop nie może oczekiwać zakończenia operacji czyszczenia, co potencjalnie pozostawia system w niespójnym stanie lub powoduje wycieki zasobów. Rozwiązaniem architektonicznym jest wzorzec drop-guard: owinięcie zasobu w strukturę guard, której implementacja Drop albo planuje synchroniczne czyszczenie (akceptując ryzyko blokowania), albo przekształca zasób w zadanie czyszczące na osobnym wątku, co zapewnia, że krytyczny inwariant (np. usunięcie pliku tymczasowego) zostanie ostatecznie narzucony bez polegania na kodzie asynchronicznym w destruktorze.
Sytuacja z życia
Opracowaliśmy usługę do przetwarzania multimediów o wysokiej przepustowości, w której tokio::spawn obsługiwało jednoczesne przesyłanie plików. Każde zadanie przesyłania zapisywało kawałki do tymczasowego pliku na dysku, przeprowadzało skanowanie wirusów za pomocą zewnętrznego procesu, a na końcu atomowo przenosiło zweryfikowany plik do trwałej puli przechowywania. Wymóg był surowy: jeśli klient się odłączył (uruchamiając anulowanie zadania za pomocą select! między skanowaniem wirusów a atomowym przeniesieniem), tymczasowy plik musiał zostać natychmiast usunięty, aby zapobiec wyczerpaniu przestrzeni dyskowej.
Rozwiązanie 1: Synchroniczne czyszczenie w Drop. Zaimplementowaliśmy strukturę TempFileGuard, która owijała std::fs::File i string ścieżki. W jej implementacji Drop wywołaliśmy std::fs::remove_file synchronicznie, aby usunąć tymczasowy plik. Zalety: Kod był prosty i gwarantował wykonanie podczas rozwiązywania stosu lub anulowania. Wady: std::fs::remove_file to blokujący syscall. Kiedy działał na wątkach roboczych runtime'u Tokio, blokował wątek na milisekundy pod dużym obciążeniem dysku, pozbawiając innych zadań zasobów i naruszając asynchroniczny kontrakt non-blocking. Dodatkowo, jeśli tymczasowy plik znajdował się na systemie plików sieciowym (NFS), blokada mogła się wydłużyć do sekund, powodując katastrofalne spowolnienia.
Rozwiązanie 2: Uruchomione zadanie czyszczące. W Drop guard, uchwyciliśmy string ścieżki i uruchomiliśmy odłączone zadanie tokio::task, aby asynchronicznie wykonać tokio::fs::remove_file. Zalety: To natychmiast oddało kontrolę do runtime'u, zachowując latencję. Wady: Jeśli runtime był już w trakcie zamykania lub pod ekstremalnym obciążeniem, zadanie czyszczące mogło nigdy się nie wykonać, prowadząc do wycieków zasobów. Dodatkowo, ten wzorzec wymagał, aby guard posiadał uchwyt Clone do runtime'u, co komplikowało czas życia struktury i wprowadzało potencjalne użycie po zwolnieniu, jeśli runtime zostałby usunięty przed guard.
Rozwiązanie 3: Eksplitywna tokken anulowania z synchronicznym zapasowym. Skorzystaliśmy z tokio_util::sync::CancellationToken i ustrukturyzowaliśmy logikę przesyłania, aby sprawdzić, czy wystąpiło anulowanie przed atomowym przeniesieniem. Jeśli było anulowane, spróbowano wykonać synchroniczne usunięcie tylko wtedy, gdy plik był poniżej pewnego rozmiaru (szybkie usunięcie), w przeciwnym razie był on w kolejce do dedykowanego wątku czyszczącego (uruchomionego za pomocą std::thread) z kanałem. Drop guard zajmował się tylko rzadkim przypadkiem paniki, wykorzystując synchroniczne usunięcie jako ostateczność. Wybrane rozwiązanie: Wybraliśmy opcję 3. Równoważyło to deterministykę (synchroniczna ścieżka dla małych plików) z skalowalnością (wątek w tle dla wolnych operacji) przy jednoczesnym unikaniu blokowania pracowników Tokio. Rezultatem były zerowe wycieki tymczasowych plików podczas testów obciążenia z 10,000 równoczesnymi anulowaniami, a latencja p99 pozostała stabilna, ponieważ wątek w tle wchłaniał karę latencji NFS.
Co często umykają kandydatom
Dlaczego wywołanie block_on wewnątrz implementacji Drop w celu wykonania asynchronicznego czyszczenia jest zasadniczo nietrafione w większości runtime'ów asynchronicznych?
Próba wywołania block_on w ramach Drop stwarza zagrożenie reentrancy. Drop jest wywoływane synchronicznie podczas rozwiązywania stosu lub gdy przyszłość jest anulowana. Jeśli bieżący wątek jest wątkiem roboczym runtime'u Tokio (lub async-std), block_on będzie próbował doprowadzić reaktor do zakończenia dla nowej przyszłości. Jednak runtime już czeka na zakończenie bieżącego zadania (tego, które jest porzucane), aby zwolnić wątek. Prowadzi to do zakleszczenia: block_on czeka na to, aby reaktor mógł przeskanować przyszłość czyszczącą, ale reaktor nie może się rozwijać, ponieważ wątek jest zablokowany wewnątrz block_on. Dodatkowo, runtime'y takie jak Tokio wyraźnie panikują, gdy wykryją zagnieżdżone wywołania block_on, aby zapobiec temu scenariuszowi. Prawidłowe podejście polega na przeprowadzeniu czyszczenia synchronicznie (jeśli jest natychmiastowe) lub przeniesieniu go do dedykowanego wątku za pomocą kanału, nigdy nie blokując asynchronicznego wykonawcy wewnątrz destruktora.
Jak projekt metody Future::poll ogranicza anulowanie tylko do punktów oczekiwania, i dlaczego jest to istotne dla projektowania sekcji krytycznych?
Metoda Future::poll jest synchroniczna i musi szybko zwracać Poll::Ready lub Poll::Pending; nie może oddać sterowania w czasie wykonywania. Punkt oczekiwania to syntaktyczny cukier dla generowanej przez kompilator maszyny stanów przechodzącej między stanami, gdy poll zwraca Pending. Wykonawca (lub makro select!) może porzucić przyszłość tylko wtedy, gdy nie jest ona aktywnie wykonywana - w szczególności, gdy zwraca Pending i zwraca kontrolę. W związku z tym anulowanie jest atomowe w odniesieniu do wywołań poll. To jest istotne, ponieważ gwarantuje, że jakikolwiek kod pomiędzy dwoma punktami oczekiwania ("sekcja krytyczna") wykonuje się całkowicie lub wcale z perspektywy runtime'u asynchronicznego. Jednak, jeśli przyszłość posiada MutexGuard przez punkt oczekiwania (co Rust zabrania dla standardowych Mutex, ale zezwala dla tokio::sync::Mutex), anulowanie może pozostawić współdzielone dane w niespójnym stanie. Kandydaci często umykają, że muszą zapewnić, że inwarianty struktury danych są przywracane przed każdym punktem oczekiwania, a nie tylko na końcu funkcji, ponieważ anulowanie wykonuje Drop na wszystkich żywych zmiennych dokładnie w tym punkcie wstrzymania.
W kontekście std::pin::Pin, dlaczego przyszłości używane w select! muszą być albo Unpin, albo wyraźnie przypinane, i jak to zapobiega niespójności pamięci podczas częściowego usuwania?
Select! losowo skanuje wiele przyszłości. Jeśli przyszłość jest !Unpin (np. zawiera wskaźniki samoodniesienia lub intruzywne linki listy), przeniesienie jej po pierwszym pollu unieważniłoby te wskaźniki. Pin gwarantuje, że lokalizacja pamięci przyszłości pozostaje stabilna. Select! wymaga, aby przyszłości były Unpin (pozwalające na przeniesienia) lub już przypięte do określonej lokalizacji pamięci (stos lub sterta). Gdy gałąź zostaje zakończona, select! porzuca inne przyszłości. Jeśli przyszłość była Unpin, jest przenoszona do kleju usuwania. Jeśli była przypięta, jest usuwana na miejscu. Gwarancja bezpieczeństwa pamięci wynika z Pin, zapewniającego, że drop jest wywoływane na przyszłości pod jej oryginalnym adresem pamięci, zapobiegając problemom z użyciem po zwolnieniu lub wskaźnikami wiszącymi, które mogłyby powstać, gdyby przyszłość samoodniesienia została przeniesiona (nawet do zniszczenia) po jej przeskanowaniu. Kandydaci często pomijają, że Pin wpływa nie tylko na skanowanie, ale także na semantykę zniszczenia anulowanych przyszłości.