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