Hi Daniel,

Thanks for the response, Daniel.

"What? What part "blocks" in the described operation? You loop until it is
done, so of course the entire loop won't complete until it is done but each
single curl_multi_perform() surely doesn't block for any lengthy period?"

Apologies for incorrect use of words. What I meant was that the loop
terminates only after response is received irrespective of the timeout. Is
this the expected behavior?

"Well, first we don't know what your script does but the connect timeout of
course only is for the actual conne, ct and I get the impression your script
doesn't delay that."

You are correct, script doesn't delay connect timeout.

My application requires to be responsive. I am setting timeout in order to
ensure that(I am willing to sacrifice unavailability of data for the sake of
responsiveness). Moreover, my application is multi-threaded (one multi
handle per thread) on RHEL4. Are there any platform limitations?

Here is the perl script, which I am using.
I place it in apache's cgi-bin dir. It is invoked by calling http://
<server-ip-addr/cgi-bin/script.pl
--------------------------------------------------------------------------------------------------------------------------------------------------------------
#!/usr/bin/perl -w
use Time::HiRes qw( usleep ualarm gettimeofday tv_interval nanosleep
                             clock_gettime clock_getres clock_nanosleep
clock
                             stat );
#----------changes this to modify timeout -----------------
 $milliseconds = 20;
#-----------------------------------------------------------
 $microseconds = $milliseconds*1000;
 usleep($microseconds);

print <<END_of_Multiline_Text;
Content-type: text/plain

name1=value1
name2=value2
name3=value3
END_of_Multiline_Text
----------------------------------------------------------------------------------------------------------------------------------------

Thanks,
Ameya

Dont think you are,
Know you are.
-Legendary Morpheus in The Matrix

On Sat, Dec 27, 2008 at 12:44 AM, Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Sat, 27 Dec 2008, ameya agnihotri wrote:
>
> However, I don't want my application to be blocked for more than say
>> 300ms.
>>
>
> I don't think the multi interface can guarantee this, even if I believe it
> will be true most of the time.
>
> In order to achieve this, I have done the following:
>>
>> curl_easy_setopt(curl_easy_handle, CURLOPT_CONNECTTIMEOUT_MS, 50);
>> //example
>> timeout values
>> curl_easy_setopt(curl_easy_handle, CURLOPT_TIMEOUT_MS, 150); //example
>> timeout values.
>>
>
> Setting very strict timeouts will only cause your transfers to fail more
> frequently, they will not make the interface any more non-blocking.
>
> I later call curl_multi_perform()(in while loop)
>> I do a curl_multi_fdset(), do a select() and then call
>> curl_multi_perform()
>> again ( This all is done in a loop, till still_running returned is 0).
>>
>> In order to test timeouts, I have written a perl script and I have placed
>> in say http://testserver/cgi-bin/a.pl.
>> A delay of 10secs is programmed in the script. So, server, for sure delays
>> response for 10 secs.
>>
>> However, the client side curl connection doesn't timeout. I blocks till it
>> gets all the data.
>>
>
> What? What part "blocks" in the described operation? You loop until it is
> done, so of course the entire loop won't complete until it is done but each
> single curl_multi_perform() surely doesn't block for any lengthy period?
>
> What is the expected behaviour of millisecond timeouts??
>>
>
> Well, first we don't know what your script does but the connect timeout of
> course only is for the actual connect and I get the impression your script
> doesn't delay that.
>
> Then, the timeout timer has been reported before to be shaky for the multi
> interface (work on this would be appreciated) and then I get to tell people
> that the "total time" timeout makes little sense most often for the multi
> interface anyway since your app is in full control and can easily remove the
> easy handle anytime it thinks the timeout has been reached.
>
> None of these problems imply any blocking behavior though.
>
> --
>
> / daniel.haxx.se
>
Received on 2008-12-26