On Mon, 28 Apr 2008, Christopher Palow wrote:

> The timeout splay tree¹s key, which servers as a queue of timeouts, only has
> second granularity. When a timeout (in this case a connection timeout) is
> less than a second in the future and less than the time till the next whole
> second, Curl_is_connected() will reinsert this connection to the front of
> the queue with a call to Curl_expire(). This can cause busy looping of
> poll() until a connect() succeeds or we¹ve busy looped long enough that the
> connection timeout expired. Busy looping for up to a second is no fun.

Evil they are, yes indeed. Nice work tracking down this flaw btw!

> We may also want to bound the number of iterations in the timeout loop of
> multi_socket() to detect other possible busy loops.

"Bound" it in what way you mean?

> My proposed fix is to make the splay tree¹s key be in microseconds instead
> of seconds. Thoughts?

It's a very reasonable idea and something I've been wanting myself. I'm all
for it.

The only problem with your specific patch is that libcurl also builds and runs
on 32bit systems with C89 compilers and they have no "int64_t" - in fact they
may have no 64 bit int types at all! Thus, the fix needs to be somewhat more
complicated to take those outdated systems into account as well... :-O

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html