Почему libcurl нуждается в опции `CURLOPT_NOSIGNAL` и какие побочные эффекты включены?

Question

Я потратил много времени, чтобы выяснить, почему многопоточное приложение libcurl врезается в Linux. Я видел на форумах, что я должен использовать CURLOPT_NOSIGNAL, чтобы обойти эту проблему. Хорошо, никаких проблем, но есть ли какая-либо информация о том, какие побочные эффекты могут создать? Если CURLOPT_NOSIGNAL = 0 ошибочно, почему libcurl вообще нуждается в этой опции, когда даже мобильные устройства имеют многоядерные процессоры, и поэтому многие приложения используют несколько потоков для использования этой аппаратной многозадачности?

Answer 1

По умолчанию разрешение DNS использует сигналы для реализации логики тайм-аута, но это небезопасно: сигнал может быть выполнен в другом потоке, чем исходный поток, который его запускал.

Когда libcurl не построен с поддержкой async DNS (это означает, что с помощью разрешающей способности с резьбой или c-ares), вы должны установить опцию CURLOPT_NOSIGNAL в 1 в многопоточном приложении.

Вы можете найти более подробную информацию по этой теме здесь:

• http://curl.haxx.se/libcurl/c/libcurl-tutorial.html#Multi-threading
• http://www.redhat.com/archives/libvir-list/2012-September/msg01960.html
• http://curl.haxx.se/mail/lib-2013-03/0086.html

Почему Libcurl нужен этот вариант вообще в наше время?

Главным образом по устаревшим причинам, но также и потому, что не все приложения используют libcurl в многопоточном контексте.

Это еще что-то, что активно обсуждается. Смотрите это recent discussion:

Libcurl не имеет резьбы на своем собственном, что она нуждается в защиту, и он не знает, что нить библиотеку/концепции вы используете поэтому он не может по своему собственному набору обратных вызовов. Это было предметом обсуждения до этого, и есть действительно действующие причины пересмотреть то, что мы можем и должны делать, но это то, как дела обстоят с тех пор, как навсегда и до сих пор. [...], но я всегда открыт для дальнейших обсуждений!