On Thu, 19 Aug 2010, Paul Harris wrote:
I am using the curl_multi_perform() mechanism, and using select() to wait for action, with a timeout of 1 second. I was NOT calling curl_multi_perform() after select() timed out, I was just calling select() again until I got some action or gave up after 60 seconds.
That's not right. You need to call curl_multi_perform() even on (some of the) timeouts as well so that it can deal with its own timeout handling.
Should I even be using curl_multi_perform ? I tried looking for some code with google, and found this bug suggesting its buggy: https://trac.transmissionbt.com/ticket/1844
That bug report is A) very old and B) not detailed enough to help anyone using libcurl. We have bugs in libcurl, and older libcurls had more bugs than more recent ones. The fact that we had bugs in the past shouldn't really be a factor when you decide whether to use curl_multi_perform() or not in a modern libcurl version. At least in my opinion.
Also, I am now using curl_multi_timeout() to specify to select how long to wait. BUT, there seems to be a problem with the documentation and code. Both the code and documentation suggest that it will return MILLIseconds, however I am seeing timeout values of 300,000 which look a lot like MICROseconds to me... and that is consistent with the timeval struct, which has a member for seconds, and tv_usec ie microseconds... not milliseconds.
300000 milliseconds is 300 seconds which is 5 minutes and I believe that is indeed the timeout libcurl uses for connects by default so yes, curl_multi_timeout() will return that when it has reached the phase where it waits for the connect to complete. Why is that a problem?
-- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
