curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

time to reconsider CURL_GLOBAL_ACK_EINTR ?

From: Daniel Stenberg via curl-library <curl-library_at_cool.haxx.se>
Date: Thu, 9 Jan 2020 07:59:03 +0100 (CET)

Hi,

As we're starting to discuss fixing the thread-safety issues in
curl_global_init(), we need to clean up the parts of that logic that is our
own creation.

One of those things is the CURL_GLOBAL_ACK_EINTR flag. It is stored in a
global variable and thus not thread-safe. It is documented as:

   "When this flag is set, curl will acknowledge EINTR condition when
   connecting or when waiting for data. Otherwise, curl waits until full
   timeout elapses."

1. Can we perhaps change to *always* abort these select() loops on EINTR ?
Surely we don't get signals that often so that it will make a significant
difference?

2. Should we make this a curl_easy_setopt() option instead? There are some
call path done in the multi interface that doesn't actually have an easy
handle. Either we have it as a curl_multi_setopt() option as well or maybe we
just acknowledge it by default there?

-- 
  / daniel.haxx.se | Get the best commercial curl support there is - from me
                   | Private help, bug fixes, support, ports, new features
                   | https://www.wolfssl.com/contact/
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html
Received on 2020-01-09