Why libcurl needs `CURLOPT_NOSIGNAL` option and what are side effects when it is enabled?

Question

I spent a lot of time to investigate why multithreaded libcurl application crashes on Linux. I saw in forums that I have to use CURLOPT_NOSIGNAL to bypass this problem. Ok, no problems, but are there any information what side effects can it create? If CURLOPT_NOSIGNAL = 0 is buggy, why libcurl needs this option at all nowadays when even mobile devices have multicore processors and that is why a lot of applications use multiple threads to use this hardware multitasking support?

Answer 1

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!