libcurl 多線程使用注意事項 - Balder~專欄 - 博客頻道 - CSDN.NEThtml
(1), 超時(timeout)
libcurl 是 一個很不錯的庫,支持http,ftp等不少的協議。使用庫最大的心得就是,不仔細看文檔,僅僅看着例子就寫程序,是一件危險的事情。個人程序崩潰了,我 懷疑是本身代碼寫的問題,後來發現是庫沒用對。不仔細看文檔(有時候文檔自己也比較差勁,這時除了看仔細外,還要多動腦子,考慮它是怎麼實現的),後果很 嚴重。不加思索的使用別人的庫或者代碼,有時候很愜意,可是出問題時,倒是寢食難安的。
1. CURLcode curl_global_init(long flags); 在多線程應用中,須要在主線程中調用這個函數。這個函數設置libcurl所需的環境。一般狀況,若是不顯式的調用它,第一次調用 curl_easy_init()時,curl_easy_init 會調用 curl_global_init,在單線程環境下,這不是問題。可是多線程下就不行了,由於curl_global_init不是線程安全的。在多個線 程中調用curl_easy_int,而後若是兩個線程同時發現curl_global_init尚未被調用,同時調用 curl_global_init,悲劇就發生了。這種狀況發生的機率很小,但可能性是存在的。
2. libcurl 有個很好的特性,它甚至能夠控制域名解析的超時。可是在默認狀況下,它是使用alarm + siglongjmp 實現的。用alarm在多線程下作超時,自己就幾乎不可能。若是隻是使用alarm,並不會致使程序崩潰,可是,再加上siglongjmp,就要命了 (程序崩潰的很可怕,core中幾乎看不出有用信息),由於其須要一個sigjmp_buf型的全局變量,多線程修改它。(一般狀況下,能夠每一個線程一個 sigjmp_buf 型的變量,這種狀況下,多線程中使用 siglongjmp 是沒有問題的,可是libcurl只有一個全局變量,全部的線程都會用)。
具體是相似 curl_easy_setopt(curl, CURLOPT_TIMEOUT, 30L) 的超時設置,致使alarm的使用(估計發生在域名解析階段),如前所述,這在多線程中是不行的。解決方式是禁用掉alarm這種超時, curl_easy_setopt(curl, CURLOPT_NOSIGNAL, 1L)。
這樣,多線程中使用超時就安全了。可是域名解析就沒了超時機制,碰到很慢的域名解析,也很麻煩。文檔的建議是 Consider building libcurl with c-ares support to enable asynchronous DNS lookups, which enables nice timeouts for name resolves without signals. c-ares 是異步的 DNS 解決方案。
引自:http://gcoder.blogbus.com/logs/54871550.html
調用libcurl下載,而後使用netstat查看發現有大量的TCP鏈接保持在CLOSE_WAIT狀態
查看libcurl的文檔說明,有這樣一個選項:
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).
也就是說,默認狀況下libcurl完成一個任務之後,出於重用鏈接的考慮不會立刻關閉
若是沒有新的TCP請求來重用這個鏈接,那麼只能等到CLOSE_WAIT超時,這個時間默認在7200秒甚至更高,太多的CLOSE_WAIT鏈接會致使性能問題
解決方法:
curl_easy_setopt(curl, CURLOPT_FORBID_REUSE, 1);
最好再修改一下TCP參數調低CLOSE_WAIT和TIME_WAIT的超時時間