cURL / Mailing Lists / curl-library / Single Mail


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

From: Kamil Dudka <>
Date: Tue, 6 Oct 2009 21:17:36 +0200

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:

> > 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.

List admin:
Received on 2009-10-06