cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: debugging a crash in Curl_pgrsTime/checkPendPipeline?

From: <johansen_at_sun.com>
Date: Tue, 11 Aug 2009 15:41:47 -0700

Hi Daniel,
I have a follow-up question about Curl_do.

On Fri, Aug 07, 2009 at 12:40:40AM +0200, Daniel Stenberg wrote:
> On Thu, 6 Aug 2009, johansen_at_sun.com wrote:
>> Is it possible to nuke the portion of Curl_do that attempts reconnects
>> entirely, or is it serving some other purpose? It looks like it's just
>> causing bugs for users of the pipeline'd multi-interface.
>
> Quite possibly it should not be attempted while in a pipeline.
>
> The code is there for the case when a connection is re-used and the
> SocketIsDead() thinks the connection is fine, but as soon as anything is
> attempted to get done (sent) on the socket it dies. Then that logic sets
> up a new connection again and moves on from there. We should be able to
> detect when that situation might happen compared to the pipelining
> scenario you have.

In transfer.c there's a routine called Curl_retry_request() that checks
a bunch of other counters about the request before returning a boolean
value about whether it's safe to retry the connection or not. It looks
to me like Curl_do() should either be calling this code, or performing
similar checks on the amount of data transferred.

In both easy and multi only call this code on the perform part of
the connection, but at least in the case I saw, we were getting data in
the do phase of the connection too.

Do you see anything wrong with such an approach?

Thanks,

-j
Received on 2009-08-12