On 10 January 2014 22:42, caballist caballist
<caballist_at_acclaimsystems.eu> 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
Received on 2014-01-12