cURL / Mailing Lists / curl-library / Single Mail


Re: curl_global_init performance

From: Kamil Dudka <>
Date: Sun, 01 Sep 2013 10:26:17 +0200

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

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.

List admin:
Received on 2013-09-01