From 232ad6549a684505efcbb6ed9d7a78943cc5f817 Mon Sep 17 00:00:00 2001 From: Daniel Stenberg Date: Tue, 10 Aug 2010 11:02:07 +0200 Subject: multi: support timeouts Curl_expire() is now expanded to hold a list of timeouts for each easy handle. Only the closest in time will be the one used as the primary timeout for the handle and will be used for the splay tree (which sorts and lists all handles within the multi handle). When the main timeout has triggered/expired, the next timeout in time that is kept in the list will be moved to the main timeout position and used as the key to splay with. This way, all timeouts that are set with Curl_expire() internally will end up as a proper timeout. Previously any Curl_expire() that set a _later_ timeout than what was already set was just silently ignored and thus missed. Setting Curl_expire() with timeout 0 (zero) will cancel all previously added timeouts. Corrects known bug #62. --- docs/KNOWN_BUGS | 5 ----- 1 file changed, 5 deletions(-) (limited to 'docs') diff --git a/docs/KNOWN_BUGS b/docs/KNOWN_BUGS index 42611d62c..96478917d 100644 --- a/docs/KNOWN_BUGS +++ b/docs/KNOWN_BUGS @@ -54,11 +54,6 @@ may have been fixed since this was written! handle with curl_easy_cleanup() and create a new. Some more details: http://curl.haxx.se/mail/lib-2009-04/0300.html -62. CURLOPT_TIMEOUT does not work properly with the regular multi and - multi_socket interfaces. The work-around for apps is to simply remove the - easy handle once the time is up. See also: - http://curl.haxx.se/bug/view.cgi?id=2501457 - 61. If an upload using Expect: 100-continue receives an HTTP 417 response, it ought to be automatically resent without the Expect:. A workaround is for the client application to redo the transfer after disabling Expect:. -- cgit v1.2.3