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:

http://www.mozilla.org/projects/nspr/tech-notes/nonblockingio.html

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

Kamil
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2009-10-06