Why libcurl needs `CURLOPT_NOSIGNAL` option and what are side effects when it is enabled?
By default the DNS resolution uses signals to implement the timeout logic but this is not thread-safe: the signal could be executed on another thread than the original thread that started it.
When libcurl is not built with async DNS support (which means threaded resolver or c-ares) you must set the CURLOPT_NOSIGNAL option to 1 in your multi-threaded application.
You can find more details related to this topic here:
- 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
Why libcurl needs this option at all nowadays?
Mainly for legacy reasons, but also because not all applications use libcurl in a multi-threaded context.
This is still something that is actively discussed. See this recent discussion:
libcurl has no threads on its own that it needs to protect and it doesn't know what thread library/concept you use so it cannot on its own set the callbacks. This has been the subject for discussion before and there are indeed valid reasons to reconsider what we can and should do, but this is how things have been since forever and still are. [...] but I'm always open for further discussions!