cURL / Mailing Lists / curl-library / Single Mail


Re: limits of independent curl connections

From: Tom K. <>
Date: Tue, 26 Feb 2013 11:15:40 -0600

> When running curl_race.exe in a long sequence here, I don't see any problem.
> But in run_many.bat you start so many processes in parallel that you hit
> this problem. Buffer/stack overflow, starved Winsock buffers, runtime DLL
> limits etc.

I am not sure if you are speculating or if you were able to detect
these things? Like I said, I have been unable to find any way to
debug this as it happens as it locks out my system. If you can
describe how I can monitor these metrics then I can verify that I'm
avoiding the problem.

> What happens if you experiment with other 'start' options? E.g.
> 'start /BELOWNORMAL'?

Using /BELOWNORMAL makes it lock up quicker it seems. It's always
somewhat random, though that seems consistent.

> I agree with Daniel that this problem is outside the
> scope of libcurl.

I am not claiming that libcurl is doing the wrong thing. I'm just
trying to understand what the problem is so I can accurately avoid it.
 I can write whatever code to avoid it, that is fine. If I can't
measure what I'm fixing then I could be masking the problem. Masked
problems tend to show up in the middle of the night. :)

> I'm not sure the MS C++ is as good as other C++ compilers. You seems to
> be using VC++8 which is quite old. So you should try a recent GNU C++ (and
> maybe Watcom C++) to rule out libcurl from the equation.

How would a different compiler rule out libcurl?

> PS. In the project-file I saw you did use '-D_SCL_SECURE_NO_WARNINGS'.
> Why?

This is fairly common practice with MSVC, whether good or bad. It
disables warnings about safe versions of the printf family of
functions. It will also warn if you disable checked iterators, which
is common on windows because of performance.

It shouldn't be required for this code sample, though it came along
with my cmake file when I copied the project.
List admin:
Received on 2013-02-26