On Saturday, August 31, 2013 19:04:25 Dave Reisner wrote: > On Fri, Aug 30, 2013 at 11:01:20PM +0200, Daniel Stenberg wrote: > > On Fri, 30 Aug 2013, Tim Ruehsen wrote: > > >The 'time' command is not very exact, it gives just a direction. I > > >agree, that in normal situations (user starting curl to download > > >one file), a difference of a few milliseconds do not matter at > > >all. But what about scripts, that download small files in a loop > > >in a fast network... e.g. using wget takes 10s while curl would > > >take 50s ? > > > > 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. It should be possible to move to get done > > before the first use of OpenSSL much more easily than I thought > > before. > > 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. > > > You up to having a go at a patch? > > 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).
This would badly break curls built against NSS, in which case we need to initialize with CURL_GLOBAL_SSL for _any_ crypto including random number generation, NTLM, metalink, etc. Kamil ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
