Python-prokurilaj kontroloj: kial Future.cancel() lasas fadenojn daŭre funkcii

Unu laboranto trovas uzeblan prokurilon. Vi redonas ĝian adreson, vokas cancel sur la aliaj future, kaj atendas, ke la reta agado haltos. Eble ĝi ne haltos.

Future povas esti nuligita antaŭ ol ĝia callable komenciĝas. Post kiam fadeno jam plenumas peton, nuligo de ĝia Future ne interrompas tiun soketan operacion. La laboranto bezonas sian propran limigitan retan operacion kaj purigan vojon.

Ankaŭ gravas la vivotempo de la plenumilo. Forlasi kuntekston de ThreadPoolExecutor atendas, ke ĝia laboro finiĝos. Trovi unu rapidan rezulton kaj poste atendi plurajn malrapidajn laborantojn povas igi la totalan prokraston de la alvokanto tute malsimila al la raportita latenteco de la venkinto.

Limigu la kuradon antaŭ ol ĝi komenciĝos

• Limigu la nombron de samtempaj kontroloj anstataŭ sendi senliman publikan liston. La senpaga prokurila listo provizas kandidatojn por la enigo de la kontrolilo, dum la protokolo de ĉiu finpunkto restas por la laboranto.
• Donu al ĉiu peto taŭgan konektan kaj legan politikon.
• Donu al la alvokanto totalan decidbuĝeton.
• Difinu, kiu ellasi aŭ fermas rezultojn de laborantoj, kiuj postvivas la decidon.

Atendi malpli por Future ne samas kiel mallongigi ĝian suban peton. Same, forlasi la rezulton ne tuj liberigas ĉiun retan rimedon.

La unua sukcesa rezulto ankaŭ estas nur la unua sukcesa kontrolo. Ĝi povas dependi de planado, kaŝmemoritaj konektoj kaj la konkreta kontrolocelo. Ĝi ne pruvas, ke la finpunkto estas universale la plej rapida aŭ ke la reala tasko sukcesos.

Ofte malgranda retenita baseno kun freŝaj observoj estas pli simpla ol kuri kontraŭ la tuta listo antaŭ ĉiu elŝuto. Uzu la rezulton de la reala operacio por ĝisdatigi la rikordon, kun kontrolita rekupera politiko por fiaskoj. La antaŭkontrolo devus gajni sian koston anstataŭ duobligi ĉiun taskon pro kutimo.