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
Received on 2014-01-10