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