Почему pthread_cancel в libcurl стал историей: причины, последствия и альтернативы

Юридические новости

В мире разработки сетевых приложений стабильность и производительность имеют первостепенное значение. Одним из ключевых элементов в этой сфере является корректное и эффективное разрешение DNS-имен. Библиотека libcurl, часто используемая для реализации сетевых клиентов, долгое время сталкивалась с проблемой блокирующего вызова getaddrinfo(), который мог затормозить работу всей программы при долгой работе с именами хоста. В попытке решить эту проблему разработчики libcurl внедрили использование функции pthread_cancel, чтобы прерывать вызывающие getaddrinfo потоки, однако эта идея столкнулась с серьезными техническими препятствиями, и совсем недавно была выведена из кода. В данной статье мы подробно рассмотрим причины, побудившие к отказу от pthread_cancel, чем вооружились разработчики взамен и какие перспективы открываются для будущего DNS-резолвинга в подобных библиотеках.

Изначально проблема заключалась в том, что getaddrinfo() - стандартная POSIX-функция для разрешения DNS-имен - является блокирующей и не предоставляет встроенных механизмов прерывания. Это значит, что если DNS-сервер долго не отвечает или настроены нестабильные сети, вызов getaddrinfo() может "зависнуть" на длительное время, что сильно ухудшало отзывчивость приложений, использующих libcurl. Чтобы обойти это ограничение, разработчики решили запускать getaddrinfo() в отдельном pthread - отдельном потоке POSIX - что позволяло остальному коду libcurl продолжать работу, не блокируясь в ожидании ответа DNS. Однако такой подход породил собственные сложности. После запуска потока с getaddrinfo необходимо было корректно его завершить.

Использование pthread_join для ожидания завершения потока было бы блокирующим, возвращая исходную проблему, а pthread_detach, наоборот, мог привести к бесконтрольному росту фоновых потоков, что негативно сказывалось на потреблении ресурсов. Чтобы решить эту дилемму, был внедрен вызов pthread_cancel, призванный прервать работу потока с getaddrinfo, освободив ресурсы немедленно и без блокировок. Теоретически идея выглядела элегантной: поток запущен, если нужно прервать - вызываем pthread_cancel и не ждем его завершения. Но, к сожалению, реальность оказалась куда сложнее. Появились жалобы пользователей и баг-репорты, в которых указывалось на утечки памяти при отмене потоков, особенно при большом количестве запросов.

 

Детальное исследование исходников glibc выявило причину - механизм getaddrinfo в glibc читает файл /etc/gai.conf для сортировки возвращаемых адресов. При этом чтение этого файла происходит через fopen, который является точкой отмены (cancellation point) для pthread_cancel. Если поток прерывается по пути чтения /etc/gai.conf, то выделенные для ответов getaddrinfo ресурсы не освобождаются, и возникает утечка памяти.

 

Учитывая что libcurl может выполнять очень много вызовов разрешения имен, накопление утечек становится реальной и серьезной проблемой. Судя по всему, glibc не предусмотрела полноценной защиты от подобных сценариев отмены потоков в getaddrinfo, что значительно ограничивает возможности безопасного использования pthread_cancel для прерывания вызовов DNS-резолвинга на базе glibc. После тщательного анализа ситуации команда libcurl приняла непростое решение отказаться от использования pthread_cancel и вернуться к более консервативному подходу - либо ждать завершения потоков с помощью pthread_join, либо принимать определенные ограничения производительности и возможного блокирования. Несмотря на то что такой шаг может показаться откатом, он является осознанным выбором в пользу надежности и предотвращения накопления ошибок и утечек в долгосрочной перспективе. Для разработчиков и пользователей libcurl эта ситуация стала сигналом о необходимости альтернативных способов резолвинга DNS.

 

Одним из таких решений является использование библиотеки c-ares, которая реализует полностью неблокирующий асинхронный DNS-резолвинг без создания дополнительных потоков. c-ares обеспечивает высокую отзывчивость и не сталкивается с описанными проблемами утечек памяти при отмене запросов. Однако у c-ares есть свои ограничения: он не всегда может гарантировать такой же уровень совместимости и функционала, как системный вызов getaddrinfo. Особенно это касается сложных настроек и правил, которые управляются в /etc/gai.conf и подобными системными компонентами.

Это означает, что выбор между glibc getaddrinfo с его надежностью и c-ares с его неблокирующим подходом зависит от конкретных требований и компромиссов в проекте. История с pthread_cancel в libcurl подчеркивает сложность управления многопоточностью, отменой операций и управления ресурсами в современных программных системах. Проблемы с поддержкой отмены функций на системном уровне могут иметь далеко идущие последствия для приложений, особенно тех, что работают на высоконагруженных серверах или в условиях ограниченных ресурсов. В итоге отказ от pthread_cancel стал шагом к более устойчивому и понятному коду, пусть и с потерей некоторого удобства неблокирующего DNS-резолвинга. Разработчики получили ценный опыт и показали пример взвешенного подхода к решению сложных инженерных задач, ориентируясь на практическую пользу и надежность.

Современный мир сетевого программирования продолжает развиваться, а DNS остается одним из наиболее сложных, но важных элементов инфраструктуры. Развитие асинхронных моделей, улучшение системных библиотек и поиск новых подходов к отмене блокирующих вызовов - вот пути, которые помогут повысить производительность и стабильность приложений в будущем. Важно следить за обновлениями libcurl и смежных библиотек, так как разработчики не оставляют попыток сделать DNS-резолвинг быстрым, безопасным и эффективным в любых условиях и на любых платформах. .