我花了很多时间来研究为什么多线程libcurl应用程序在Linux上崩溃。我在论坛中看到我必须使用CURLOPT_NOSIGNAL来绕过这个问题。好的，没有问题，但是有什么信息可以创造它的副作用吗？如果CURLOPT_NOSIGNAL = 0有问题，为什么libcurl现在甚至需要这个选项，甚至移动设备都有多核处理器，这就是许多应用程序使用多个线程来使用这种硬件多任务支持的原因？
答案 0 :(得分：16)
默认情况下，DNS解析使用信号来实现超时逻辑，但这不是线程安全的：信号可以在启动它的原始线程之外的另一个线程上执行。
如果libcurl不是使用异步DNS支持构建的（这意味着线程解析器或c-ares），则必须在多线程应用程序中将CURLOPT_NOSIGNAL选项设置为1。
您可以在此处找到与此主题相关的更多详细信息：
为什么libcurl现在都需要这个选项？
主要是出于遗留原因，但也因为并非所有应用程序都在多线程上下文中使用libcurl。
这仍然是积极讨论的问题。见recent discussion：
libcurl没有自己需要保护的线程，而且它不知道 你使用什么线程库/概念，所以它不能自己设置回调。 这是以前讨论的主题，确实有效 重新考虑我们能做什么和应该做什么的理由，但这就是事情的方式 从那以后永远都是。 [...]但我总是愿意接受进一步的讨论！