On Tue, 24 Jan 2017, Pawel Veselov wrote:
I quite don't like the fact that the signal seems to interrupt the "wrong" thread. Or interrupted the thread too late:
Threads and signals don't match very good. I'd recommend you to switch off libcurl's use of signals then (CURLOPT_NOSIGNAL).
There are no threads that have their stack traces in Curl_resolv, which should be the location when the alarm goes off. Note that I compiled libcurl without thread resolver. The same exact problem happens when thread resolver is on, however.
libcurl doesn't use alarm() with the threaded resolver (nor with the c-ares backend) so it's unclear to me how the "same exact problem" can trigger then.
Can you provide a way for us to reproduce?
It also looks that the whole alarm functionality, even if threaded resolver is used, is not MT safe because of shared setjmp buffer, and the fact that the waiting (actual setjmp/longjmp calls) is done on the calling thread. Or am I missing something here?
The alarm() thing is a hideous thing in general and it should only be used if you really cannot find any other way to live your life. When built with the threaded resolver, the setjmp buffer doesn't matter since it won't be used.
-- / daniel.haxx.se ------------------------------------------------------------------- Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library Etiquette: https://curl.haxx.se/mail/etiquette.html
