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

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html