Las solicitudes proxy paralelas necesitan una propiedad separada de los handles de libcurl
Mantenga los handles de libcurl bajo la propiedad de un solo hilo a la vez cuando las solicitudes usen proxies diferentes.
Una opción de proxy pertenece a un handle easy de libcurl. Cambiar esa opción desde un hilo mientras otro hilo realiza una transferencia en el mismo handle infringe las reglas de propiedad del handle.
libcurl es seguro para hilos cuando se siguen sus reglas documentadas. No sincroniza internamente el acceso simultáneo arbitrario a un handle. Dé a los trabajadores concurrentes sus propios handles, o transfiera la propiedad solo cuando el usuario anterior haya terminado.
La interfaz share tiene requisitos de bloqueo y límites separados. No es permiso para que cada trabajador modifique todos los ajustes de un handle easy compartido.
Los ejemplos antiguos de hilos proxy suelen incluir callbacks de bloqueo para versiones antiguas de bibliotecas TLS. Consulte la documentación actual sobre seguridad de hilos para el backend TLS y la compilación reales. Copiar callbacks históricos de OpenSSL en una aplicación actual no sustituye una propiedad correcta del handle.
Inicialice el estado global de la biblioteca según los requisitos de inicio documentados antes de usarlo de forma concurrente. Para las solicitudes públicas permitidas a través de intermediarios públicos, la lista de proxies gratuitos ofrece candidatos para la opción de proxy de cada trabajador; haga coincidir el protocolo con la compilación de libcurl. Para cada operación fallida, conserve el proxy configurado del handle y su propio resultado de error. Una variable global de “proxy actual” es un mal identificador cuando hay varias transferencias en curso.