On Fri, Aug 07, 2009 at 12:40:40AM +0200, Daniel Stenberg wrote:
> On Thu, 6 Aug 2009, johansen_at_sun.com wrote:
>
> I'm sorry I haven't commented on your previous mail yet, things have been
> very busy in my end lately.

It seems that it is just as well. The new error that I've run into does
make it worth re-considering some aspects of the fix that I proposed. ;)

>> It looks like when the re-connect happens the client never bothers to
>> set the file pointer back to the head of the file. In fact, it appears
>> that there really isn't any code in libcurl that is set up to do this.
>
> That's because libcurl can't seek in any file, since it is given to the
> lib by a callback! There is however a CURLOPT_SEEKFUNCTION that
> translates into a conn->seek_func() that should be able to do the job.
> Hopefully. ;-)

I was under the impression that the CURLOPT_SEEKFUNCTION applied only to
the read function and not the write function. In this case, I'm
seeing extra bytes written to the file.

>> 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.

To catch that case, would I want to test Curl_isPipeliningEnabled() or
Curl_llist_count(easy->easy_conn->send_pipe) == 0, or something else
entirely?

Thanks for the quick response.

-j
Received on 2009-08-07