On Mon, 26 Sep 2011, Martin Lemke wrote:

> I think I found out a clear case for reproducing this problem (I am working
> with 7.21.3 but the same crash occurs in 7.22.0 as well). This is a
> combination of few factor with the "pipelining" in multi being the most
> important one. Without the pipelining the crash doesn't happen. With
> pipelining it happens.

Ah, pipelining! We should probably try to write up a test case that does N
pipelined requests against a slow server with a very short timeout on the
requests. Or at least one of the requests. It would be so much easier and
better if we had a proper test suite case to work with.

> In fact I expected that pipelining would bring an increase of transfer
> speed, the result is just opposite, apparently either I misunderstood the
> feature, or it is not implemented properly. Anyway, due to this
> consideration I disabled it anyway.

I can't exclude the possibility of one or more bugs, but pipelining is not a
silver-bullet to faster transfers. There's a reason why browsers these days
have moved beyond 6 simultaneous connections to each host.

Pipelining has its advantages and disadvantages. There's much more to read
about about this and to experiment with and most likely you need a set of
multiple pipelined connections to get the most out of it - and with the
current libcurl API you don't easily do that.

And just to be clear: libcurl does not itself set _any_ limit to amount of
simultaneous connections to the same host.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html