|
(1), 超時(timeout) libcurl 是 一個很不錯的庫，支持http,，ftp等很多的協(xié)議,。使用庫最大的心得就是，不仔細(xì)看文檔,，僅僅看著例子就寫程序,，是一件危險的事情。我的程序崩潰了,，我 懷疑是自己代碼寫的問題,，后來發(fā)現(xiàn)是庫沒用對。不仔細(xì)看文檔（有時候文檔本身也比較差勁,，這時除了看仔細(xì)外,，還要多動腦子，考慮它是怎么實現(xiàn)的）,，后果很 嚴(yán)重,。不加思索的使用別人的庫或者代碼，有時候很愜意,，但是出問題時,，卻是寢食難安的。1. CURLcode curl_global_init(long flags); 在多線程應(yīng)用中,，需要在主線程中調(diào)用這個函數(shù),。這個函數(shù)設(shè)置libcurl所需的環(huán)境。通常情況,，如果不顯式的調(diào)用它,，第一次調(diào)用 curl_easy_init()時，curl_easy_init 會調(diào)用 curl_global_init，在單線程環(huán)境下,，這不是問題,。但是多線程下就不行了，因為curl_global_init不是線程安全的,。在多個線 程中調(diào)用curl_easy_int,，然后如果兩個線程同時發(fā)現(xiàn)curl_global_init還沒有被調(diào)用，同時調(diào)用 curl_global_init,，悲劇就發(fā)生了,。這種情況發(fā)生的概率很小，但可能性是存在的,。 2. libcurl 有個很好的特性,，它甚至可以控制域名解析的超時。但是在默認(rèn)情況下,，它是使用alarm + siglongjmp 實現(xiàn)的,。用alarm在多線程下做超時，本身就幾乎不可能,。如果只是使用alarm,，并不會導(dǎo)致程序崩潰，但是,，再加上siglongjmp,，就要命了 （程序崩潰的很可怕，core中幾乎看不出有用信息）,，因為其需要一個sigjmp_buf型的全局變量,，多線程修改它。（通常情況下,，可以每個線程一個 sigjmp_buf 型的變量,，這種情況下，多線程中使用 siglongjmp 是沒有問題的,，但是libcurl只有一個全局變量，所有的線程都會用）,。 具體是類似 curl_easy_setopt(curl, CURLOPT_TIMEOUT, 30L) 的超時設(shè)置,，導(dǎo)致alarm的使用（估計發(fā)生在域名解析階段），如前所述,，這在多線程中是不行的,。解決方式是禁用掉alarm這種超時， curl_easy_setopt(curl, CURLOPT_NOSIGNAL, 1L),。 這樣,，多線程中使用超時就安全了。但是域名解析就沒了超時機(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 解決方案。 引自：http://gcoder./logs/54871550.html 調(diào)用libcurl下載,，然后使用netstat查看發(fā)現(xiàn)有大量的TCP連接保持在CLOSE_WAIT狀態(tài) 查看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). 也就是說，默認(rèn)情況下libcurl完成一個任務(wù)以后,，出于重用連接的考慮不會馬上關(guān)閉 如果沒有新的TCP請求來重用這個連接,，那么只能等到CLOSE_WAIT超時，這個時間默認(rèn)在7200秒甚至更高,，太多的CLOSE_WAIT連接會導(dǎo)致性能問題 解決方法： curl_easy_setopt(curl, CURLOPT_FORBID_REUSE, 1); 最好再修改一下TCP參數(shù)調(diào)低CLOSE_WAIT和TIME_WAIT的超時時間 |
|
|
