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