On Mon, 27 Jan 2003, Ward, David wrote:

> Thanks for the response, your original response was clear but it seemed to
> contradict the official documentation as did my test. I was confused as
> the man page indicates the timer value is the "maximum time in seconds that
> you allow the libcurl transfer operation to take" and therefore I assumed
> that the transfer was the request-response to the ultimate destination and
> the entire transfer would use a single timer i.e. not split the transfer
> into service components and that that one timer operated using a signal.
> This assumption was incorrect.

Right, that was not a correct assumption. libcurl *used* to do that, once
upon the time. But since signals are evil, we avoid them as much as possible.
Unfortunately, we can't completely avoid signals just yet.

> From my tests it appears that the CURLOPT_TIMEOUT is safe to use in a
> multi-threaded environment if you disable signals on your thread ... you
> wont get the DNS timeout feature but you will recover if your destination
> server hangs.

Correct. But that part about "disable signals on your thread" is not really a
portable thing is it? (Not that might matter here, but it still makes the
documentation correct I believe, or am I wrong?)

-- 
 Daniel Stenberg -- curl, cURL, Curl, CURL. Groks URLs.
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com