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