On Thu, May 15, 2008 at 08:31:34AM +0200, Daniel Stenberg wrote:
> On Wed, 14 May 2008, Jeff Weber wrote:
>> libraries: curl-7.18.1, libssh2-0.18,
>> If I start the test with no network connection, [and not using DNS names],
>> hangs every time. Here's a backtrace of the hung thread:
>> (gdb) thread 3
>> [Switching to thread 3 (Thread 16386 (LWP 6805))]#0 0x4024e2da in poll ()
>> from /lib/libc.so.6
>> (gdb) bt
>> #0 0x4024e2da in poll () from /lib/libc.so.6
>> #1 0x0806c037 in Curl_socket_ready (readfd=-1, writefd=6,
>> at select.c:218
>> #2 0x080643ac in waitconnect (sockfd=6, timeout_msec=299998) at
> Ouch. It shouldn't wait that blocking in there. It should only wait for 1
> second, call the progress callback and then get back to the waiting...
In all my tests, I defined a progress callback to enforce timeouts.
In the test where I started an FTP upload to a non-DNS IP address with
a broken network connection (i.e. curl should fail to connect to
remote host), poll() was passed a timeout of 299998 msec. In another
test where I was in the middle of uploading N files, and broke the
network connection, poll() was passed a timeout of 3600000 msec. Is
there a bug, in that registering a progress callback should have
changed all poll() timeouts to 1000 msec, but didn't?
I am writing an embedded application that requires the transfer return
within a predefined timeout (e.g. 5min). Above, I had been
implementing the timeout logic in the progress callback. I
previously overlooked the CURLOPT_CONNECTTIMEOUT, CURLOPT_TIMEOUT,
CURLOPT_FTP_RESPONSE_TIMEOUT capabilities. I just added these, and
happily, these have all aborted my FTP transfers as advertised. The
Curl documentation still warns that active FTP connections can block.
Can I depend upon CURLOPT_CONNECTTIMEOUT, CURLOPT_TIMEOUT,
CURLOPT_FTP_RESPONSE_TIMEOUT to always timeout a FTP connection?
> Will you be able to write up a patch?
That depends if I will need the progress callback to enforce my FTP connect,
Received on 2008-05-16