Python proxy-ellenőrzések: miért hagyja a Future.cancel() futni a szálakat

Egy worker talál egy használható proxyt. Visszaadod a címét, cancel-t hívsz a többi future-ön, és arra számítasz, hogy a hálózati tevékenység leáll. Lehet, hogy nem.

Egy Future törölhető, mielőtt a callable elindul. Ha egy szál már végrehajt egy kérést, a Future törlése nem szakítja meg azt a socket-műveletet. A workernek saját korlátozott hálózati műveletre és tisztítási útra van szüksége.

A végrehajtó élettartama is számít. A ThreadPoolExecutor kontextusának elhagyása megvárja a munka befejezését. Egy gyors eredmény megtalálása, majd több lassú worker megvárása teljesen másképp mutathatja a hívó teljes késleltetését, mint a győztes jelentett latenciája.

Korlátozd a versenyt, mielőtt elkezdődik

• Korlátozd az egyidejű ellenőrzések számát ahelyett, hogy korlátlan nyilvános listát küldenél be. A ingyenes proxy lista jelölteket ad az ellenőrző bemenetéhez, miközben minden végpont protokollja megmarad a worker számára.
• Adj minden kérésnek megfelelő kapcsolódási és olvasási szabályt.
• Adj a hívónak átfogó döntési költségkeretet.
• Határozd meg, ki üríti vagy zárja le a döntést túlélő workerek eredményeit.

Kevésbé várni egy Future-re nem ugyanaz, mint lerövidíteni a mögöttes kérést. Hasonlóképpen, az eredmény elhagyása nem szabadít fel azonnal minden hálózati erőforrást.

Az első sikeres eredmény is csak az első sikeres ellenőrzés. Függhet az ütemezéstől, a gyorsítótárazott kapcsolatoktól és a konkrét ellenőrzési céltól. Nem bizonyítja, hogy a végpont egyetemesen a leggyorsabb, vagy hogy a valódi feladat sikerülni fog.

Gyakran egy kis megtartott készlet friss megfigyelésekkel egyszerűbb, mint minden letöltés előtt a teljes listával versenyezni. Használd a valódi művelet eredményét a rekord frissítéséhez, a hibákra vonatkozó ellenőrzött helyreállítási szabályzattal. Az előzetes ellenőrzésnek ki kell érdemelnie a költségét, ahelyett hogy szokásból megduplázna minden feladatot.