I see. Thanks for sharing the background. I definitely agree with you that we can start with changing the timeout granularity first.

So, first of all, we could add a #ifdef to make WIN32 a special case here.

Then, for Linux and other platforms, I think we need to handle it in two different cases.
First case, when user is not providing their own timer function, the lib is using its default, then we have some sort of "guarantee" or knowledge of the timer granularity (based on what timer the system has to provide). For example, if system has clock_gettime() then granularity could be pretty fine, and we could use some short timeout adjustment, such as 3ms or so (to be on the safe side, still).

And the second case is when user is providing their own timer function. In this case, there is no way for the lib to tell the accuracy of their timer, hence the lib should not make any assumption. In this case, I'd suggest that we provide an additional curl easy option for the user to adjust the value based on their best knowledge of their timer. Of course, the curl easy option for this purpose could have some good all-rounder default, such as 5ms.

What do you think?

---
** [bugs:#1228] curl multi timeout does not work with timeout set less than 40ms**
**Status:** open
**Created:** Wed May 22, 2013 09:45 PM UTC by Hang
**Last Updated:** Mon Jun 03, 2013 08:50 PM UTC
**Owner:** Daniel Stenberg
In the latest source code lib/multi.c:
~~~~
2178   now.tv_usec += 40000; /* compensate for bad precision timers that might've
2179                            triggered too early */
2180   if(now.tv_usec >= 1000000) {
2181     now.tv_sec++;
2182     now.tv_usec -= 1000000;
2183   }
2184 
2185   /*
2186    * The loop following here will go on as long as there are expire-times left
2187    * to process in the splay and 'data' will be re-assigned for every expired
2188    * handle we deal with.
2189    */
2190   do {
2191     /* the first loop lap 'data' can be NULL */
2192     if(data) {
2193       do
2194         result = multi_runsingle(multi, now, data->set.one_easy);
2195       while(CURLM_CALL_MULTI_PERFORM == result);
~~~~
"now" has been artificially incremented by 40ms, and then passed in to the multi_runsingle(...) below. 
Then, multi_runsingle() will check for timeouts:
~~~~
964       timeout_ms = Curl_timeleft(data, &now,
965                                  (easy->state <= CURLM_STATE_WAITDO)?
966                                  TRUE:FALSE);
~~~~
so, if the timeout setting is less than 40ms for the curl easy handle, the Curl_tvdiff(*nowp, data->progress.t_startsingle) will return 39ms at the very beginning of the curl easy request, and therefore timeout the request even before it gets started. 
It will always prompt something like this (almost immediately after the first curl_multi_perform() call):
http://foo.com => (28) Connection timed out after 39 milliseconds
---
Sent from sourceforge.net because you indicated interest in <https://sourceforge.net/p/curl/bugs/1228/>
To unsubscribe from further messages, please visit <https://sourceforge.net/auth/subscriptions/>