On Fri, Aug 07, 2009 at 08:54:04AM +0200, Daniel Stenberg wrote:
> On Thu, 6 Aug 2009, johansen_at_sun.com wrote:
>>> 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.
>
> Ah, no. I wasn't paying enough attention. You're right, that's for the
> read stream... Perhaps we need to add a similar one for the write stream?

I wondered the same thing myself, but I don't have enough experience to
make a broad generalization. I don't see any code or documentation that
forbids users from passing a FILE * to CURLOPT_WRITEDATA that has been
fseek'd to a different offset in the file. If we write a method that
seeks back to 0 when Curl_do() loses the connection, then we'll break
the ability for users to do that. On the other hand, it seems like a
bit of a contrived case. However, that case lead me to consider simply
returning an error to be a better approach. (It's hard to anticipate
what the library's callers might be trying to accomplish).

>> 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?
>
> I would assume the latter or similar, as if the connection is actually in
> use for pipelining already. But I'm not saying it MUST be done this way.
> You're clearly doing a lot more work and testing with pipeling than me,
> so I hope you can suggest a fair approach!

I'll try a couple of different approaches. I will send out an updated
patch once I find something that works well.

OpenSolaris is making use of this code pretty heavily now. We picked
libcurl for the packaging client because it allowed us to perform
pipelined downloads. Currently, users on recent dev builds are using
this code. It will get even more use once we push the 6-month-ish
stable build in early 2010.

-j
Received on 2009-08-07