Just a quick heads up to note that if libcurl is compiled for use in any POSIX multithreaded environment (*nix) then USE_ALARM_TIMEOUT should be forced to undefined (#undef USE_ALARM_TIMEOUT) or equivalent preventative measures should be taken.
The code appears to assume that the ALARM signal will be handled on the thread calling Curl_resolv_timeout (and there are comments noting that the rest of the application will be run from within a signal handler). This is an erroneous assumption - *any* thread in the process could be selected by the OS to receive any signal. When this happens the thread in receipt of the signal is forced to masquerade as the thread which called Curl_resolv_timeout. The original thread that called Curl_resolve_timeout continues in it's original form - still within the call to Curl_resolv. This has been observed in an application I am responsible for - the thread selected by the OS for receipt of the ALARM signal happens to frequently be in possession of a lock on a mutex, which when the thread was then forced to vicariously live the life of the thread which originally called Curl_resolv_timeout it caused the application to hang (as the mutex it holds is then never released). Further issues may become apparent for other applications: Threads can mysteriously disappear from their assigned tasks and when the original calling thread of Curl_resolv_timeout actually does timeout on the Curl_resolv call, it will be try to unwind a call stack which has already been unwound by a 'stolen' thread - I imagine that will not be a pretty sight. We worked around this with CURLOPT_NOSIGNAL but that really shouldn't have been necessary.
------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
