Comprobaciones de proxy en Python: por qué Future.cancel() deja los hilos en marcha
Entienda por qué cancelar futuros pendientes no detiene las comprobaciones de red activas y acote una carrera de proxy sin afirmar que demuestra la salud del destino.
Un worker encuentra un proxy utilizable. Devuelve su dirección, llama a cancel sobre los otros futuros y espera que la actividad de red se detenga. Puede que no.
Un Future se puede cancelar antes de que su callable comience. Cuando un hilo ya está ejecutando una solicitud, cancelar su Future no interrumpe esa operación de socket. El worker necesita su propia operación de red acotada y una ruta de limpieza.
La vida del ejecutor también importa. Salir de un contexto de ThreadPoolExecutor espera a que su trabajo termine. Encontrar un resultado rápido y luego esperar a varios workers lentos puede hacer que el retraso total del llamador no se parezca en nada a la latencia reportada por el ganador.
Acode la carrera antes de empezarla
- Limite el número de comprobaciones simultáneas en lugar de enviar una lista pública ilimitada. La lista gratuita de proxies proporciona candidatos para la entrada del comprobador, con el protocolo de cada punto final conservado para el worker.
- Dé a cada solicitud una política de conexión y lectura adecuada.
- Dé al llamador un presupuesto global de decisión.
- Defina quién drena o cierra los resultados de los workers que sobreviven a la decisión.
Esperar menos a un Future no es lo mismo que acortar su solicitud subyacente. Del mismo modo, abandonar el resultado no libera de inmediato todos los recursos de red.
El primer resultado exitoso también es solo la primera comprobación exitosa. Puede depender de la planificación, las conexiones en caché y el destino concreto de la comprobación. No establece que el punto final sea universalmente el más rápido ni que la tarea real vaya a tener éxito.
A menudo, un pequeño grupo retenido con observaciones recientes es más simple que competir con toda la lista antes de cada descarga. Use el resultado de la operación real para actualizar el registro, con una política de recuperación controlada para los fallos. La comprobación previa debería ganarse su coste en lugar de duplicar cada tarea por costumbre.