On Sat, 31 Aug 2013, Dave Reisner wrote:
When thinking further about this subject, it struck me that
SSL_load_error_strings() isn't mentioned to have any multi-threading
problems in the man page.
Is this really true? Assuming that this is to be treated as a singleton, how
do you handle the case where you have multiple threads with a CURL* handle
for each? The openssl code for loading the error strings doesn't appear to
be thread safe despite the lack of any mention otherwise in the manpage.
Uh right, thanks for your clear head. I might have been a bit too omptimistic
there...
Alternate idea: What about a new option for the curl tool to control the
value passed to curl_global_init? Or something simpler: --ssl and --nossl
flags to "toggle" between CURL_GLOBAL_ALL and (CURL_GLOBAL_ALL &
~CURL_GLOBAL_SSL).
I don't think it would fly.
It would force curl to tell libcurl to not get HTTPS urls and not to follow
redirects to HTTPS as it would break if it did. It would also be a weird
option that hardly anyone would use (execpt for those who truly do loop 6000
times with a fast network).
I think we're back to square one. The only way to delay the SSL init is to
make sure it has thread mutexes around it...
--
/ daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
