Python-proxykontroller: varför Future.cancel() låter trådar fortsätta köra

En worker hittar en användbar proxy. Du returnerar dess adress, anropar cancel på de andra futurena och förväntar dig att nätverksaktiviteten ska stoppa. Det kanske den inte gör.

En Future kan avbrytas innan dess callable startar. När en tråd redan kör en begäran avbryter inte avbrytandet av dess Future den socket-operationen. Workern behöver sin egen begränsade nätverksoperation och städväg.

Executorns livslängd spelar också roll. Att lämna en ThreadPoolExecutor-kontext väntar på att arbetet ska bli klart. Att hitta ett snabbt resultat och sedan vänta på flera långsamma workers kan få den totala fördröjningen för anroparen att se helt annorlunda ut än vinnarens rapporterade latens.

Begränsa racet innan det börjar

• Begränsa antalet samtidiga kontroller i stället för att skicka in en obegränsad offentlig lista. Den kostnadsfria proxylistan tillhandahåller kandidater för kontrollerns indata, med varje ändpunkts protokoll bevarat för workern.
• Ge varje begäran en lämplig anslutnings- och läspolicy.
• Ge anroparen en övergripande beslutbudget.
• Definiera vem som tömmer eller stänger resultat från workers som överlever beslutet.

Att vänta kortare på en Future är inte samma sak som att göra dess underliggande begäran kortare. På samma sätt frigör inte övergivandet av resultatet omedelbart alla nätverksresurser.

Det första lyckade resultatet är också bara den första lyckade kontrollen. Det kan bero på schemaläggning, cachelagrade anslutningar och den specifika kontrollens destination. Det fastställer inte att ändpunkten är universellt den snabbaste eller att den verkliga uppgiften kommer att lyckas.

Ofta är en liten bibehållen pool med färska observationer enklare än att tävla mot hela listan före varje nedladdning. Använd resultatet av den verkliga operationen för att uppdatera posten, med en kontrollerad återhämtningspolicy för fel. Förkontrollen bör tjäna in sin kostnad i stället för att dubbla varje uppgift av vana.