On Wed, 7 Jan 2015, Alex Lyakas wrote:
As I mentioned, I am using curl-7.35.0. But I have just retested with
the latest version (curl-7.39.0), and I see the same results, i.e.,
Curl_splaycomparekeys returning -1:
multi_timeout: return 0, multi->timetree->key=[2738:950134] now=[2739:129497]
multi_timeout: return 0, multi->timetree->key=[2738:950134] now=[2739:129576]
multi_timeout: return 0, multi->timetree->key=[2738:950134] now=[2739:129656]
multi_timeout: return 0, multi->timetree->key=[2738:950134] now=[2739:129726]
Any suggestion how to move forward with this issue?
How about coming up with a recipe we can use to reproduce the case?
The outdated node is supposed to be removed from the splay tree since it is
already out of date - all out of date nodes should be removed. If you can
reproduce the case, you should be able to single-step through and get an idea
why it isn't happening.
I'm thinking about a new option for curl_multi_setopt() to tell
curl_multi_wait() how long to wait if it finds no file descriptors at all to
wait for... Or something like that.
Yes, this sounds awesome! To be precise: we should use this new option
only if there are no *curl* file descriptors to wait for (i.e., not
including the extra_fds). So the logic would be something like this:
if curlfds==0:
curl_timeout=<new option value>
else:
curl_timeout=as returned by multi_timeout()
if extra_fds >0:
final_timeout = min(user-specified timeout, curl_timeout)
else
final_timeout = curl_timeout
Does this make sense?
Yes, I believe that matches my thinking. It should make it possible to write
simpler code using curl_multi_wait().
Want to make an attempt to write a patch for such a functionality?
--
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
