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: http://www.mozilla.org/projects/nspr/tech-notes/nonblockingio.html
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. rob
smime.p7s
Description: S/MIME Cryptographic Signature
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
