Hi Josh,
I think I have encountered the same problem. It happens when you have
multiple threads doing HTTPS requests simultaneously. It's due to the random
initialisation of SSL: instead of beeing done only one time, this consuming
process is executed by each thread. The problem is that in cURL, this
initialisation is protected by a static global variable (ssl_seeded in
lib/ssluse.c). When many threads start requests at the same time, they all
check the ssl_seeded value and they all call the random_the_seed() function.
What I have done is to toggle the initial value of ssl_seeded to TRUE and to
ensure myself that OpenSSL is correctly seeded before doing any request
(call RAND_screen() for example on Windows). It's not a very good patch but
it works.
Hope it helps,
Arnaud.
  -----Message d'origine-----
  De : curl-users-bounces_at_cool.haxx.se
[mailto:curl-users-bounces_at_cool.haxx.se]De la part de Yehoshua Hershberg
(yhershbe)
  Envoye : Monday, July 25, 2005 3:02 PM
  A : curl-users_at_cool.haxx.se
  Objet : threading issue

  I have encountered a problem using libcurl. I have libcurl linked
statically to a DLL on a windows machine. I have multiple simultaneous
threads sending http/s requests. What I have found is that for a single
thread I get a round trip time of ~0.3 seconds. If I run 10 simultaneous
threads I get a round trip time of ~3 seconds, which lead me to believe that
there is something that is running serially in libcurl. When I run the whole
thing in a profiler I find that Curl_easy_perform spends 99% of its time in
NtWaitForSingleObject.

  Does anyone have any idea why this is happening or how I could deal with
it?

  -Josh
Received on 2005-07-26