Comprobacións de proxy en Python: por que Future.cancel() deixa os fíos en marcha

Un worker atopa un proxy utilizábel. Devolve o seu enderezo, chama cancel sobre os outros futuros e espera que a actividade de rede se deteña. Pode que non.

Un Future pódese cancelar antes de que comece o seu callable. Cando un fío xa está executando unha solicitude, cancelar o seu Future non interrompe esa operación de socket. O worker necesita a súa propia operación de rede acoutada e unha ruta de limpeza.

A vida do executor tamén importa. Saír dun contexto de ThreadPoolExecutor espera a que o seu traballo remate. Atopar un resultado rápido e despois esperar varios workers lentos pode facer que o atraso total do chamador non se pareza en nada á latencia informada polo gañador.

Acoute a carreira antes de empezala

• Limite o número de comprobacións simultáneas en lugar de enviar unha lista pública ilimitada. A lista gratuíta de proxies fornece candidatos para a entrada do comprobador, mantendo o protocolo de cada punto final para o worker.
• Dea a cada solicitude unha política de conexión e lectura axeitada.
• Dea ao chamador un orzamento global de decisión.
• Defina quen drena ou pecha os resultados dos workers que sobreviven á decisión.

Esperar menos por un Future non é o mesmo que acurtar a súa solicitude subxacente. Do mesmo xeito, abandonar o resultado non libera de inmediato todos os recursos de rede.

O primeiro resultado exitoso tamén é só a primeira comprobación exitosa. Pode depender da planificación, das conexións na caché e do destino concreto da comprobación. Non establece que o punto final sexa universalmente o máis rápido nin que a tarefa real vaia ter éxito.

A miúdo un pequeno conxunto retido con observacións recentes é máis simple que competir con toda a lista antes de cada descarga. Use o resultado da operación real para actualizar o rexistro, con unha política de recuperación controlada para os fallos. A comprobación previa debería gañar o seu custo en vez de duplicar cada tarefa por costume.