cURL / Mailing Lists / curl-library / Single Mail


Re: nss: timeouts within Curl_nss_recv() and Curl_nss_send()

From: Rob Crittenden <>
Date: Tue, 06 Oct 2009 15:29:46 -0400

Kamil Dudka wrote:
> On Tuesday 06 of October 2009 20:57:39 Rob Crittenden wrote:
>>> I don't think so. The timeouts are computed wrong, nobody has noticed it
>>> so far. Which platform does it need actually?
>> Wait. You are asking the wrong question.
> Yes, I am.
> Is there any chance the socket is not in non-blocking mode? Otherwise there
> is no reason to compute a value which is ignored anyway:

Ok, yes you can save a few milliseconds...

curl can open sockets in either blocking or non-blocking:
Curl_ssl_connect_nonblocking() and Curl_ssl_connect().

>>> How do you know the timeouts given to PR_Recv()/PR_Send() are correct? It
>>> simply can't be the constant associated with handle. I don't think this
>>> is the way how libcurl deals with the remainder of timeout.
>> This is closer. The problem isn't that the conversion is ugly, it is
>> that it isn't doing the right thing. You are right about the
>> computation, seconds vs milliseconds, but assuming I'm reading the
>> comments in url.c right the timeout is supposed to apply to the whole
>> request and not an individual operation within that request.
> That's why you need to use Curl_timeleft() to compute the remainder I think.
>> This is very out-of-whack and I'm wondering if the framework code
>> changed and the nss portion was not updated.
>> So yes, looks like something should change but I'm not entirely sure
>> what value should be passed to timeout for PR_Recv/PR_Send.
> What about e.g. zero?
> I can't see any timeout computation in the OpenSSL nor GnuTLS equivalents.

Well, I'd consider those bugs too.


List admin:

Received on 2009-10-06