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