On 10 January 2014 22:42, caballist caballist <[email protected]> wrote:
> 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 is correct as far as it goes, but it should not be a problem as long as the person writing the multi-threaded application is aware of how signals are to be handled in this case. Specifically, use pthread_sigmask(3) instead of sigprocmask(3), and you can filter signals to exactly the thread(s) you want. (On at least some versions of Linux sigprocmask is effectively the same as pthread_sigmask IIRC. That doesn't seem to be the case on what I'm currently running on my desktop though - a newer Linux. In any case these functions are very different on e.g. AIX). I have coded several applications and libraries this way and have no trouble leading the signals to exactly where I want them. -Tor ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
