Python-proxykontrollar: kvifor Future.cancel() lèt trådar halda fram

Éin worker finn ein brukande proxy. Du returnerer adressa, kallar cancel på dei andre futureane og ventar at nettverksaktiviteten stoppar. Det gjer han kanskje ikkje.

Ein Future kan avbrytast før callable-en startar. Når ein tråd alt utfører ein førespurnad, avbryt ikkje avbrytinga av Future-en hans den socket-operasjonen. Workeren treng sin eigen avgrensa nettverksoperasjon og oppryddingsveg.

Levetida til executor-en har òg noko å seia. Å forlata ein ThreadPoolExecutor-kontekst ventar på at arbeidet blir ferdig. Å finna eitt raskt resultat og deretter venta på fleire trege workarar kan få den totale forseinkinga for kallaren til å sjå heilt annleis ut enn den rapporterte latensen til vinnaren.

Avgrens kapplauget før det startar

• Avgrens talet på samtidige kontrollar i staden for å senda inn ei ubegrensa offentleg liste. Den gratis proxylista gjev kandidatar til inndataa til kontrolløren, medan protokollen til kvar endepunkt blir halden for workeren.
• Gje kvar førespurnad ein passande tilkoplings- og lesepolicy.
• Gje kallaren eit samla avgjerdsbudsjett.
• Definer kven som tømmer eller lukkar resultat frå workarar som overlever avgjerda.

Å venta kortare på ein Future er ikkje det same som å gjera den underliggjande førespurnaden kortare. På same måte frigjer ikkje det å forlata resultatet alle nettverksressursar med ein gong.

Det første vellukka resultatet er òg berre den første vellukka kontrollen. Det kan avhenga av planlegging, bufra tilkoplingar og den konkrete kontrollestaden. Det fastslår ikkje at endepunktet er universelt det raskaste eller at den verkelege oppgåva vil lukkast.

Ofte er ein liten halden pool med nylege observasjonar enklare enn å kapplaufast mot heile lista før kvar nedlasting. Bruk resultatet av den verkelege operasjonen til å oppdatera posten, med ein kontrollert attopprettingspolicy for feil. Førkontrollen bør tena inn kostnaden sin i staden for å dobla kvar oppgåve av vane.