libcurl與CLOSE_WAIT轉(zhuǎn)載自：http://blog.sunshow.net/2010/03/libcurl-and-close-wait/
調(diào)用libcurl下載，然后使用netstat查看發(fā)現(xiàn)有大量的TCP連接保持在CLOSE_WAIT狀態(tài)
查看libcurl的文檔說(shuō)明，有這樣一個(gè)選項(xiàng)：
CURLOPT_FORBID_REUSE
Pass a long. Set to 1 to make the next transfer explicitly close the connection when done. Normally, libcurl keeps all connections alive when done with one transfer in case a succeeding one follows that can re-use them. This option should be used with caution and only if you understand what it does. Set to 0 to have libcurl keep the connection open for possible later re-use (default behavior).
也就是說(shuō)，默認(rèn)情況下libcurl完成一個(gè)任務(wù)以后，出于重用連接的考慮不會(huì)馬上關(guān)閉
如果沒(méi)有新的TCP請(qǐng)求來(lái)重用這個(gè)連接，那么只能等到CLOSE_WAIT超時(shí)，這個(gè)時(shí)間默認(rèn)在7200秒甚至更高，太多的CLOSE_WAIT連接會(huì)導(dǎo)致性能問(wèn)題
解決方法：
curl_easy_setopt(curl, CURLOPT_FORBID_REUSE, 1); 最好再修改一下TCP參數(shù)調(diào)低CLOSE_WAIT和TIME_WAIT的超時(shí)時(shí)間
libcurl 使用筆記轉(zhuǎn)載自：http://gcoder.blogbus.com/logs/54871550.html
libcurl 是一個(gè)很不錯(cuò)的庫(kù)，支持http，ftp等很多的協(xié)議。使用庫(kù)最大的心得就是，不仔細(xì)看文檔，僅僅看著例子就寫(xiě)程序，是一件危險(xiǎn)的事情。我的程序崩潰了，我懷疑是自己代碼寫(xiě)的問(wèn)題，后來(lái)發(fā)現(xiàn)是庫(kù)沒(méi)用對(duì)。不仔細(xì)看文檔（有時(shí)候文檔本身也比較差勁，這時(shí)除了看仔細(xì)外，還要多動(dòng)腦子，考慮它是怎么實(shí)現(xiàn)的），后果很?chē)?yán)重。不加思索的使用別人的庫(kù)或者代碼，有時(shí)候很愜意，但是出問(wèn)題時(shí)，卻是寢食難安的。
1. CURLcode curl_global_init(long flags); 在多線程應(yīng)用中，需要在主線程中調(diào)用這個(gè)函數(shù)。這個(gè)函數(shù)設(shè)置libcurl所需的環(huán)境。通常情況，如果不顯式的調(diào)用它，第一次調(diào)用curl_easy_init()時(shí)，curl_easy_init 會(huì)調(diào)用 curl_global_init，在單線程環(huán)境下，這不是問(wèn)題。但是多線程下就不行了，因?yàn)閏url_global_init不是線程安全的。在多個(gè)線程中調(diào)用curl_easy_int，然后如果兩個(gè)線程同時(shí)發(fā)現(xiàn)curl_global_init還沒(méi)有被調(diào)用，同時(shí)調(diào)用curl_global_init，悲劇就發(fā)生了。這種情況發(fā)生的概率很小，但可能性是存在的。
2. libcurl 有個(gè)很好的特性，它甚至可以控制域名解析的超時(shí)。但是在默認(rèn)情況下，它是使用alarm + siglongjmp 實(shí)現(xiàn)的。用alarm在多線程下做超時(shí)，本身就幾乎不可能。如果只是使用alarm，并不會(huì)導(dǎo)致程序崩潰，但是，再加上siglongjmp，就要命了（程序崩潰的很可怕，core中幾乎看不出有用信息），因?yàn)槠湫枰粋€(gè)sigjmp_buf型的全局變量，多線程修改它。（通常情況下，可以每個(gè)線程一個(gè) sigjmp_buf 型的變量，這種情況下，多線程中使用 siglongjmp 是沒(méi)有問(wèn)題的，但是libcurl只有一個(gè)全局變量，所有的線程都會(huì)用）。
具體是類(lèi)似 curl_easy_setopt(curl, CURLOPT_TIMEOUT, 30L) 的超時(shí)設(shè)置，導(dǎo)致alarm的使用（估計(jì)發(fā)生在域名解析階段），如前所述，這在多線程中是不行的。解決方式是禁用掉alarm這種超時(shí)， curl_easy_setopt(curl, CURLOPT_NOSIGNAL, 1L)。
這樣，多線程中使用超時(shí)就安全了。但是域名解析就沒(méi)了超時(shí)機(jī)制，碰到很慢的域名解析，也很麻煩。文檔的建議是 Consider building libcurl with c-ares support to enable asynchronous DNS lookups, which enables nice timeouts for name resolves without signals. c-ares 是異步的 DNS 解決方案。
libcurl 多線程使用注意事項(xiàng)
轉(zhuǎn)載自:http://blog.csdn.net/jaylong35/article/details/6439549
1、問(wèn)題來(lái)源，多線程使用Libcurl導(dǎo)致程序跑一段時(shí)間后自己退出，沒(méi)有明顯的異常。找不到合適的BUG。
最后通過(guò)查看資料和網(wǎng)上找的一些文章，發(fā)現(xiàn)，原來(lái)是信號(hào)處理的問(wèn)題：
CURLOPT_NOSIGNAL
Pass 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 closed in 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.
就是當(dāng)多個(gè)線程都使用超時(shí)處理的時(shí)候，同時(shí)主線程中有sleep或是wait等操作。如果不設(shè)置這個(gè)選項(xiàng)，libcurl將會(huì)發(fā)信號(hào)打斷這個(gè)wait從而導(dǎo)致程序退出。
所以，在使用的時(shí)候把這個(gè)選項(xiàng)設(shè)置成1就可以了.
curl_setopt(curl, CURLOPT_NOSIGNAL, 1L);
2、關(guān)于libcurl庫(kù)的初始化和關(guān)閉：curl_global_init()和curl_global_cleanup()
這兩個(gè)函數(shù)并不是線程安全的。所以只能在主線程中進(jìn)行一次的初始化和清除。
雖然這個(gè)不是一定就會(huì)有問(wèn)題，但是如果不這樣處理還是有概率發(fā)生的。