When attaching an easy handle with a URL that needs resolving (bare IP address has no problems), curl_multi_timeout() is returning the value of CURLOPT_CONNECTTIMEOUT_MS (which by default is 300 seconds).
By itself, this is not a problem, but the fact that I have 1 extra file descriptor I want to poll (this is used in my lib to receive "wakeups" from another thread and has very low activity), curl_multi_wait() decides to poll just my extra fd for up to 300 seconds. This basically causes the entire application to hang for 300 seconds.
I raise this issue because a previous version of libcurl did not exhibit this behavior. See more details on this in alexcrichton/curl-rust#227.
I expected the following
I expected curl_multi_timeout() to return some small timeout to indicate that curl_multi_wait() should not be called for very long to avoid indefinite blocking on nothing.
This is using the threaded resolver right? And no specific timeout set?
It is a bit weird to call curl_multi_timeout() to ask for the timeout to pass to curl_multi_wait() and it is probably based on a misunderstanding. The timeout to this latter function is supposed to be the maximum time your app can tolerate to wait, and you shouldn't need to ask libcurl about that...
However, I think the real bug (even if you remove the curl_multi_timeout() call might be that this logic:
Yes, libcurl is built with the threaded resolver, and I am letting libcurl use its default connect timeout (currently 300 seconds).
It is a bit weird to call curl_multi_timeout() to ask for the timeout to pass to curl_multi_wait() [...]
Ah yes, now that I look closer that is a bit silly of me, as curl_multi_wait() will effectively call curl_multi_timeout() anyway and truncate the timeout I specify to at most that value. So yeah, harmless, but rather silly to do.
So the real bug is still that timers are not being set correctly. I had a hunch, but I wasn't familiar enough with the code to deduce that.
Until my lib can use the patch for this, I'll keep doing it the silly way though, since my current workaround is to assume that if curl_multi_timeout() returns the connect timeout, then this bug is occurring and I instead pass a small timeout value to curl_multi_wait().