Mailing Lists
|
cURL Mailing List Monthly Index Single Mail
curl-tracker Archives
[curl:bugs] #1386 nosignal should be default in presence of multithreading
From: Daniel Stenberg <bagder_at_users.sf.net>
Date: Sat, 28 Jun 2014 03:14:42 +0000
USE_THREADS_POSIX is used for the resolver backend when the threaded resolver is used. It doesn't say if libcurl is otherwise used multi-threaded or not. You can use libcurl multi-threaded with or without that define. And you can use it non-threaded with or without that define...
How could libcurl "observe" that it is being used multi-threaded? And even if it could, altering a default value base on something like that seems like a documentation nightmare and risk completely surprising users! Not to mention the ABI breakage.
Doesn't the multi-threading advice already mention *NOSIGNAL ?
--- ** [bugs:#1386] nosignal should be default in presence of multithreading** **Status:** pending **Created:** Fri Jun 27, 2014 12:15 AM UTC by Ami Fischman **Last Updated:** Fri Jun 27, 2014 09:35 PM UTC **Owner:** Daniel Stenberg The implementation of alarms/timeouts in libcurl is thread-hostile: while the rest of libcurl is multithread-safe in that different handles can be used on different threads concurrently, alarms are implemented in terms of siglongjmp with a global/static sigjmp_buf curl_jmpenv variable shared among all threads/handles. As a result a timed-out Curl_resolv_timeout (for example) will longjmp to an arbitrary caller, not necessarily the one that timed out. A workaround for multithread-requiring clients is to curl_easy_setopt(handle, CURLOPT_NOSIGNAL, true); on all handles. It would be better if libcurl detected that it was built for multi-threaded use and force-enable nosignal. In other words, enforce at build-time that at most one of "!nosignal" / "threads" is enabled. Related thread from 2006 discussing the incompatiblity: http://curl.haxx.se/mail/lib-2006-09/0214.html (but it seems to have petered out without action, which is why this bug is just asking for the build system to prevent misuse rather than asking for the underlying bug to be fixed, which is a much harder problem). --- Sent from sourceforge.net because curl-tracker@cool.haxx.se is subscribed to https://sourceforge.net/p/curl/bugs/ To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/curl/admin/bugs/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.Received on 2014-06-28 These mail archives are generated by hypermail. |
Page updated March 21, 2014.
web site info