Thanks for your answer !

You wrote :
> ... and you are *sure* that the server you connect to has no
problems at all
> dealing with 100 simultaneous connects?
Yes it's the problem !
My provider engine is a Windows 2000 sp2 server using IIS 5, and my
test engine is also a Windows 2000 sp2 but using Apache v1.3.24. When
I use our intranet on "Compaq Tru64 UNIX V5.1A" spanning 30 apache
processes, I have no more problem !
Refused connection could(?) be caused by intrusion detection system
(denial of service attack, ...) on W2K ?

-----Original Message-----
From: Daniel Stenberg [mailto:daniel_at_haxx.se]
Sent: lundi, 5. août 2002 17:08
To: Torche Philippe
Cc: libcurl Mailing list
Subject: Re: Multi-threading problem

On Mon, 5 Aug 2002, Torche Philippe wrote:

> When I run my multi-threading test code (see attached file), I have
> approximately (0 to 10% probability) chance of having erroneous
> transactions. The "Return" from curl_easy_perform is 7 (Connect
failed).

... and you are *sure* that the server you connect to has no problems
at all
dealing with 100 simultaneous connects?

When I try this program (with some minor modifications), I
get "couldn't
create socket" and return code 7 back on many threads, with one
occational
"libthread panic: cannot create new lwp (PID: 12855 LWP 2)" sort of
error.

I can't say I know what could possibly cause a libthread panic though.
Anyone?

Also, I can't understand why the socket() call returns error but I
would
guess that it involves some maximum number of open file descriptors or
something... (*checking*) ok, I get errno 24 back when socket()
failed:

$ grep 24 /usr/include/errno.h
#define EMFILE 24 /* Too many open files */

Also, my man page for socket() says:

  EMFILE The per-process descriptor table is full.

> If I observe 2 errors in 100 threads, I can observe only 98
connections on
> my apache access log.

Those errors being return code 7? Well then it couldn't connect so
there's
not too strange that the server doesn't log it...

> The problem no longer arises if I use a lock mutex before
> "curl_easy_perform(curl)" and unlock mutex after, but it's not
acceptable
> for me !

I realize that, but I can't yet say how or even if curl behaves
wrongly.

-- 
 Daniel Stenberg -- curl related mails on curl related mailing lists 
please
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf