This 40ms precaution was added in commit 2c72732ebf3da5e as a result of bad resolution in a windows function we use(d). Doing it unconditionally for all systems was just me trying to be careful, but I might also just have done more damage than fixing for other systems of course... I'm prepared to lower that by default (to just a few milli) and maintain 40ms for WIN32 systems until we get feedback from someone with such insights.

The problematic case for which this was made, is when using the multi_socket API and libcurl has told the application about a timeout, and that timeout is what fires off a bit early. As we don't have any IDs associated with the timeout we can't tell which timeout that fired off but we only have the times to use to check what to do. If it fires off too early, we don't run the correct actions and we don't tell the application again about the same timeout as was already first in the queue.

A possible fix could be what you're mentioning: if *socket_action() is called with TIMEOUT and nothing was found to work on, assume that happened due to a bad timer and call the application again to update/set the timeout value (which would then be for the same top node in the timeout tree).

But it is much easier to just change the timeout granularity. Let's start there! What margin value do you suggest for your case?

---
** [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 06:41 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/>