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

> >Yes. The signal is used for stopping slow DNS name resolves, nothing else.
> >So, if you don't "hang" in the name resolve for very long, then it won't
> >abort with a signal but just a normal comparison and a return.

> Thanks for the response, but I'm still non the wiser. The DNS isnt hanging
> as my http server is receiving the request and I'm forcing the http server
> to hang. My http server is just a simple socket that receives the http
> request but does not respond.

Right, then libcurl won't use a signal for the timeout.

> If I set the CURLOPT_TIMEOUT option my client times out after the requested
> time from its connection with the http server. I dont understand how this
> can happen as I've disabled the SIGALRM signal on my thread and apparently
> the timeout can only occur on reception of this signal.

Then pelase read the first paragraph of this mail one more time. I don't know
how to put it in any other words: aborting the name resolve lookup is the
only thing that uses signals.

> I started testing this feature as I have a scenario with a hanging third
> party server and the timeout feature is just what I need. However as the
> documentation warns against using this timeout in a multi-threaded
> environment I want to find out why.

Because it uses a signal to cancel dns resolves.

> I think I can solve my problem by using the CURLOPT_LOW_SPEED_LIMIT feature
> as this doesnt come with a thread warning but I'm still curious as to how
> the CURLOPT_TIMEOUT really works!

Using a signal for the name resolve (until CURLOPT_NOSIGNAL was introduced at
least), using regular comparisons for everything else. There's nothing magic.

-- 
 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