On 20/12/2018 07:42, Daniel Stenberg wrote:
> On Wed, 19 Dec 2018, Samuel Hurst via curl-library wrote:
>
>> I was not aware that this was a requirement on multi-threaded
>> applications. The CURLOPT_NOSIGNAL API documentation [1] does not
>> reference this requirement at all, which is why I've missed it.
>
> I should clarify in there!
>
>> My application is multi-threaded, but I have a dedicated thread just
>> for running curl in - there should never be another thread which calls
>> curl_multi_perform. Would I need to set CURLOPT_NOSIGNAL even in this
>> case?
>
> If you're only using curl in a single thread then you're fine to use
> CURLOPT_NOSIGNAL I think. Unless you need SIGPIPE (filtering) for
> something else.
>
> The issue when using CURLOPT_NOSIGNAL when using curl from multiple
> threads is that curl needs to ignore the signals but it can't do it
> globally for the process so it will set the ignore the entry and clear
> it again on exit. But signals are global per process so if you then
> invoke curl multiple times within the process, the ignoring/clearing of
> signals end up in a race.

Just to clarify, would building easy handles in another thread cause any
issues? I'm only doing the actual processing in one thread, but I'm
calling curl_easy_init and curl_easy_setopt in another and passing it
between them with a queue.

Looking through the easy code, it seems that it's inserting a SIGPIPE
handler only when you do easy_perform, although I note that there's one
in easy_cleanup too, I'm guessing that this is potentially where I'm
falling foul of this because my code does the cleanup in the same thread
that it builds the easy handle in the first place?

-Sam

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html