Паралелните прокси заявки изискват отделна собственост върху манипулаторите на libcurl
Дръжте манипулаторите на libcurl под собствеността на един поток в даден момент, когато заявките използват различни прокси сървъри.
Опцията за прокси принадлежи на манипулатор libcurl easy. Промяната на тази опция от един поток, докато друг поток извършва трансфер по същия манипулатор, нарушава правилата за собственост на манипулатора.
libcurl е безопасен за нишки, когато се спазват документираните му правила. Той не синхронизира вътрешно произволен едновременен достъп до един манипулатор. Дайте на паралелните работници собствени манипулатори или прехвърляйте собствеността само когато предишният потребител е приключил.
Интерфейсът share има отделни изисквания за заключване и ограничения. Това не е разрешение всеки работник да променя всяка настройка на споделен easy манипулатор.
Старите примери за прокси нишки често включват заключващи callback функции за стари версии на TLS библиотеки. Проверете текущата документация за безопасност на нишките за действителния TLS backend и компилация. Копирането на исторически OpenSSL callback функции в текущо приложение не заменя правилната собственост върху манипулатора.
Инициализирайте глобалното състояние на библиотеката съгласно документираните изисквания за стартиране, преди да го използвате едновременно. За публични заявки, разрешени през публични посредници, безплатен списък с прокси предлага кандидати за опцията за прокси на всеки работник; съобразете протокола с компилацията на libcurl. За всяка неуспешна операция запазете конфигурираното прокси на манипулатора и собствения резултат от грешка. Глобалната променлива “текущо прокси” е лош идентификатор, когато няколко трансфера са в ход.