Thanks for the quick reply Daniel!
By "built for multi-threaded" I meant USE_THREADS_POSIX. I take your point that you want to enable in the same (shared) libcurl build:
- single-threaded clients to use alarms
- multi-threaded clients without alarms

How would you feel about flipping the default once you observe multi-threaded operation?
I don't like to suggest it b/c clients that do their own synchronization _could_ be using the code today with alarms safely. I don't see a path forward that doesn't break any potential use-cases.

Perhaps the best answer is to document the list of known exceptions to the rule that different SessionHandles can be use on different threads safely?

---
** [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 02:34 AM 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.