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