Requisições proxy paralelas exigem propriedade separada dos handles libcurl
Mantenha os handles libcurl sob a propriedade de uma única thread por vez quando as requisições usam proxies diferentes.
Uma opção de proxy pertence a um handle easy do libcurl. Alterar essa opção a partir de uma thread enquanto outra thread realiza uma transferência no mesmo handle viola as regras de propriedade do handle.
O libcurl é seguro para threads quando suas regras documentadas são seguidas. Ele não sincroniza internamente acesso simultâneo arbitrário a um handle. Dê handles próprios aos workers concorrentes, ou transfira a propriedade somente quando o usuário anterior tiver terminado.
A interface share tem requisitos de bloqueio e limites separados. Não é permissão para que cada worker altere todas as configurações de um handle easy compartilhado.
Exemplos antigos de threads proxy costumam incluir callbacks de bloqueio para versões antigas de bibliotecas TLS. Verifique a documentação atual sobre segurança de threads para o backend TLS e a compilação reais. Copiar callbacks históricos do OpenSSL para uma aplicação atual não substitui a propriedade correta do handle.
Inicialize o estado global da biblioteca conforme os requisitos de inicialização documentados antes de usá-lo simultaneamente. Para requisições públicas permitidas por intermediários públicos, a lista de proxies gratuitos oferece candidatos para a opção de proxy de cada worker; combine o protocolo com a compilação do libcurl. Para cada operação malsucedida, conserve o proxy configurado do handle e seu próprio resultado de erro. Uma variável global de “proxy atual” é um mau identificador quando várias transferências estão em andamento.