On Thursday 29 August 2013 22:40:54 Daniel Stenberg wrote: > On Thu, 29 Aug 2013, Tim Ruehsen wrote: > > Wouldn't be the typical init stuff in this case look like > > > > #ifdef HAVE_THREADS > > static int init; > > mutex lock > > Yes, but that opens the usual can of worms with threads, different platforms > and different threading systems etc and we've managed to avoid threads for > so long in libcurl...
Yes, but nowadays we are slowly coming into the multi-threading / multi-core age ;-) But that OT .... I hoped I could avoid a discussion, since i am not very deep into the libcurl API (used it some years ago the last time). Looking at curl_global_init() docs, at least a programmer could defer initializing SSL by using e.g. (CURL_GLOBAL_ALL & (~CURL_GLOBAL_SSL)). And maybe later call curl_global_init() a second time with just CURL_GLOBAL_SSL, right ? The 'curl' tool could do the same right ? Or is it multi-threading or something that prevents the above mentioned two calls of curl_global_init ? > Exactly how long time are we actually talking about here, the specific > SSL_load_error_strings() call I mean? Wow, that's a "manager" question ;-) You know, the absolute time very depends on your system and how busy the systems is in the moment your are calling curl. As you see, the word 'exactly' doesn't make any sense. I wrote about the relative timing in my initial posting. I also wrote, how you can make it visible using valgring / callgrind / Kcachegrind. If you don't have KDE/Qt, there are precompiled packages (e.g. http://sourceforge.net/projects/precompiledbin/files/kcachegrind.zip/download) Regards, Tim ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
