Some time ago, when I used libcurl To Write multi-thread downloads, I encountered an inexplicable segment error.
The problem occurs when you use libcurl to open multiple threads to download files from the task queue. Because the download queue is empty, all download threads are locked in pthread_mutex_lock. At this time, Program After idle for a few seconds, the system will exit due to segmentation fault. View me repeatedly Code I didn't see any problem. I finally found the answer to the libcurl basics. It's really embarrassing. the basics are very important! The original libcurl uses alarm + siglongjmp to implement domain name resolution timeout when configure is compiled by default. When multiple threads use timeout processing, sleep or wait operations are performed in the main thread. Libcurl will send a signal to interrupt this wait and cause the program to exit. So ~, Ah! Can a warning die?
Well, who asked me not to read the document carefully at the beginning. One solution is to disable this timeout. If you are too lazy to set C-Ares, set this option to 1. curl_easy_setopt (curl, curlopt_nosignal, 1l ). However, domain name resolution does not have a timeout mechanism. Another solution is the "consider building libcurl with C-Ares support to enable asynchronous DNS lookups, which enables nice timeouts for name resolves without signals ."
The description of curlopt_nosignal is as follows:
Curlopt_nosignalpass a long. if it is 1, libcurl will not use any functions that install signal handlers or any functions that cause signals to be sent to the process. this option is mainly here to allow multi-threaded Unix applications to still set/use all timeout options etc, without risking getting signals. (Added in 7.10) If this option is set and libcurl has been built with the standard Name Resolver, timeouts will not occur while the name resolve takes place. consider building libcurl with C-Ares support to enable asynchronous DNS lookups, which enables nice timeouts for name resolves without signals. setting curlopt_nosignal to 1 makes libcurl not ask the system to ignore sigpipe signals, which otherwise are sent by the system when trying to send data to a socket which is Cloin the other end. libcurl makes an effort to never cause such sigpipes to trigger, but some operating systems have no way to avoid them and even on those that have there are some corner cases when they may still happen, contrary to our desire. in addition, using curlauth_ntlm_wb authentication cocould cause a sigchld signal to be raised.