On Tue, 12 May 2009, Luke Dashjr wrote:

> I wrote a fix for part of libcurl's "known bug #62" so that timeouts set by
> CURLOPT_TIMEOUT will be reported with curl_multi_timeout calls. This is
> needed by a product we are developing, in order to make use of curl's
> timeout framework. Is this patch acceptable as-is, or does anyone have any
> suggestions/needs for revision before it can be merged into the next version
> of libcurl?

I think the fix need to be done differently and possibly it needs a somewhat
larger take. I'll elaborate on the timeout logic...

In general within libcurl's easy handle (if we ignore the user provided
timeouts) there is only one timeout at any given time that concerns the
current transfer. It is mostly a sort of maximum allowed time for remaining in
a given state. Like resolving a host name.

This is basically what the multi interface timeout code is written to deal
with, as it makes a splay-tree sorted by the single timeout time for each
added handle. Finding the next-in-time node is a very fast operation even with
a large amount of handles in use.

When we add a user-provided timeouts to the mix we get another timeout that
will alter things. They are at least two (CURLOPT_TIMEOUT and
CURLOPT_CONNECTTIMEOUT). They need to be allowed to run in addition to the
other timeout, as if they fire we need to cancel the operation (in the
CURLOPT_CONNECTTIMEOUT case only if we're still in a connecting state). In all
other aspects, the other timeouts must remain functional.

-- 
  / daniel.haxx.se