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
