On Wed, Dec 8, 2010 at 11:21 PM, Dan Fandrich <[email protected]> wrote: > On Wed, Dec 08, 2010 at 11:03:23PM +0200, Michael Menegakis wrote: >> On Wed, Dec 8, 2010 at 10:20 PM, Dan Fandrich <[email protected]> >> wrote: >> > What locks are you talking about here? libcurl doesn't use any locks by >> > default (except when using NSS), and in a single-threaded application >> > you don't need to install things like OpenSSL or share locks. >> >> It's on normal http. >> >> I also noticed there may be a short hanging on the first first >> request, probably when the first easy is being loaded to the multi. > > You still haven't answered the question: what locks are you talking about? > Or is what you describe as a "lock" just a delay in completing the > transfer? Delays are a completely different matter, and one on the first > request is likely to be due to DNS resolution. If you turn on libcurl > logging or use a packet tracing tool like Wireshark, you should see what > is happening at the point when a delay occurs.
I said a lock, not a delay. The application is single threaded and on rapid simultaneous connections on the multi it may lock during the process. It also locks usually on the very first request. I suspect if I feed it a 'dummy' request at app initialization I may avoid that. ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.html
