Verificações de proxy em Python: por que Future.cancel() deixa threads em execução

Um worker encontra um proxy utilizável. Você retorna o endereço dele, chama cancel nos outros futures e espera que a atividade de rede pare. Pode não parar.

Um Future pode ser cancelado antes de seu callable começar. Quando uma thread já está executando uma solicitação, cancelar seu Future não interrompe essa operação de socket. O worker precisa de sua própria operação de rede limitada e de um caminho de limpeza.

A vida útil do executor também importa. Sair de um contexto de ThreadPoolExecutor espera que seu trabalho termine. Encontrar um resultado rápido e depois esperar por vários workers lentos pode fazer o atraso total do chamador não se parecer nada com a latência relatada pelo vencedor.

Limite a corrida antes de começar

• Limite o número de verificações simultâneas em vez de enviar uma lista pública ilimitada. A lista gratuita de proxies fornece candidatos para a entrada do verificador, com o protocolo de cada endpoint mantido para o worker.
• Dê a cada solicitação uma política de conexão e leitura adequada.
• Dê ao chamador um orçamento geral de decisão.
• Defina quem drena ou fecha os resultados de workers que sobrevivem à decisão.

Esperar menos por um Future não é o mesmo que encurtar sua solicitação subjacente. Da mesma forma, abandonar o resultado não libera imediatamente todos os recursos de rede.

O primeiro resultado bem-sucedido também é apenas a primeira verificação bem-sucedida. Pode depender do escalonamento, das conexões em cache e do destino específico da verificação. Não estabelece que o endpoint seja universalmente o mais rápido nem que a tarefa real terá sucesso.

Muitas vezes, um pequeno pool mantido com observações recentes é mais simples do que competir com a lista inteira antes de cada download. Use o resultado da operação real para atualizar o registro, com uma política de recuperação controlada para falhas. A verificação prévia deve pagar seu custo em vez de dobrar cada tarefa por hábito.