On Fri, 24 Jan 2003, Daniel Stenberg 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.

>Also, exactly how your operating system treats a signal that arrives when
you
>run multiple threads seem to vary a lot between different systems.

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.
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. Testing without
setting CURLOPT_TIMEOUT I get the expected behaviour of the client hanging
indefinitely.
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.
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!

-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
Received on 2003-01-27