I love it!

Hmm. I am experiencing some difficulties in Microsoft Git with this change, and reverting this PR "fixes" it.

The problem is that curl_multi_timeout() (when being called in a test that intentionally tries to access a non-existing server by connecting to http://127.0.0.1:5799/ when nobody is listening on that port) changed behavior. Previously, it kept returning a timeout of -1. Now, the timeout is instead first set to 200ms (or 199ms, sometimes). The next two calls return 300 seconds (i.e. not milliseconds), and the next three calls repeat that sequence, causing my test case to fail for different reasons than the expected one.

Is this by design? I could understand if the six attempts would now cause 200ms * 5 = one second of extra delay, but not an extra delay that had not been there before of more than 20 minutes.

FWIW when I tried to debug this, I saw that the 300 seconds come from the Curl_timeleft() call in the new cf_ip_ballers_run() call, which returns essentially the DEFAULT_CONNECT_TIMEOUT. The stack trace when that happens looks like this:

#0  cf_ip_ballers_run (bs=0x27752d8, cf=0x2775390, data=0x2772900, connected=0x5ff687) at cf-ip-happy.c:498
#1  0x00007ffb9c34bf1a in is_connected (cf=0x2775390, data=0x2772900, connected=0x5ff687) at cf-ip-happy.c:625
#2  0x00007ffb9c34c511 in cf_ip_happy_connect (cf=0x2775390, data=0x2772900, done=0x5ff687) at cf-ip-happy.c:758
#3  0x00007ffb9c35149a in Curl_conn_cf_connect (cf=0x2775390, data=0x2772900, done=0x5ff687) at cfilters.c:413
#4  0x00007ffb9c355c7d in cf_setup_connect (cf=0x27750a0, data=0x2772900, done=0x5ff687) at connect.c:387
#5  0x00007ffb9c3518b2 in Curl_conn_connect (data=0x2772900, sockindex=0, blocking=false, done=0x5ff687) at cfilters.c:498
#6  0x00007ffb9c397268 in multi_runsingle (multi=0xfb8410, nowp=0x5ff710, data=0x2772900) at multi.c:2429
#7  0x00007ffb9c397ccd in curl_multi_perform (m=0xfb8410, running_handles=0x5ff794) at multi.c:2758

This amount is then dutifully added to the splay list, from where curl_multi_timeout() obtains it.

Is this a bug, or do I now have to call cURL's API in a different way to get back the previous behavior?

Could you open a new issue for this? I think I understand to what you are referring to, but since this PR is closed, any fix of this would work better with a separate issue.

Could you open a new issue for this? I think I understand to what you are referring to, but since this PR is closed, any fix of this would work better with a separate issue.

@icing done: #18767