Sprawdzanie proxy w Pythonie: dlaczego Future.cancel() pozostawia wątki uruchomione

Jeden worker znajduje użyteczne proxy. Zwracasz jego adres, wywołujesz cancel na pozostałych future i oczekujesz, że aktywność sieciowa się zatrzyma. Może się nie zatrzymać.

Future można anulować, zanim jego callable się uruchomi. Gdy wątek już wykonuje żądanie, anulowanie jego Future nie przerywa tej operacji na sockecie. Worker potrzebuje własnej ograniczonej operacji sieciowej i ścieżki sprzątania.

Znaczenie ma też czas życia executora. Opuszczenie kontekstu ThreadPoolExecutor czeka na zakończenie jego pracy. Znalezienie jednego szybkiego wyniku, a następnie czekanie na kilka wolnych workerów, może sprawić, że całkowite opóźnienie wywołującego zupełnie nie przypomina opóźnienia zgłoszonego przez zwycięzcę.

Ogranicz wyścig, zanim się zacznie

• Ogranicz liczbę równoczesnych testów zamiast wysyłać nieograniczoną publiczną listę. Darmowa lista proxy dostarcza kandydatów na wejście testera, a protokół każdego punktu końcowego jest zachowywany dla workera.
• Daj każdemu żądaniu odpowiednią politykę połączenia i odczytu.
• Daj wywołującemu ogólny budżet decyzyjny.
• Zdefiniuj, kto opróżnia lub zamyka wyniki workerów, które przeżywają decyzję.

Krótsze czekanie na Future nie jest tym samym, co skrócenie jego bazowego żądania. Podobnie porzucenie wyniku nie uwalnia natychmiast wszystkich zasobów sieciowych.

Pierwszy udany wynik to także tylko pierwszy udany test. Może zależeć od planowania, połączeń w pamięci podręcznej i konkretnego celu testu. Nie dowodzi, że punkt końcowy jest uniwersalnie najszybszy ani że rzeczywiste zadanie się powiedzie.

Często niewielka zachowana pula z ostatnimi obserwacjami jest prostsza niż ściganie się z całą listą przed każdym pobraniem. Użyj wyniku rzeczywistej operacji do aktualizacji rekordu, z kontrolowaną polityką odzyskiwania po awariach. Wstępny test powinien zarobić na swój koszt, zamiast z przyzwyczajenia podwajać każde zadanie.