curl-library
Re: Info request about the zero copy interface (2)
Date: Tue, 6 Dec 2005 11:46:28 +0100 (CET)
On Mon, 5 Dec 2005, Legolas wrote:
> As a very bad example, give a look to the client pseudo code I have written
> taking in account what I have read up to now. I have also put in it my
> original idea in a soft way. However, that's not my idea, it's just an idea
> :)
Thanks a lot for the "mockup".
Now I can see how this suggestion is similar to my original (in text)
suggestion: libcurl calls a callback to request a buffer to store incoming
data in. The 'at least this big' argument is indeed needed.
Some further comments/ideas:
Upload
We also need to cater for uploads, where the current code calls a read
callback with a buffer pointer to have the application copy data to it. To
turn that into zero-copy, it would need to be done in a way that allows the
application to instead pass in (return?) a pointer and size with data to
upload.
File-write case
In your example psedo code you have two use-cases, but for the scope of this
discussion I'd say you can ignore the (1) case when the app simply wants to
download directly to a file, as then I can't see hwo we can avoid copies
more than we currently do (using the libcurl internal fwrite() code).
Write callback
Your example also has a modified write callback proto, and while we can
certainly have that we should not re-use CURLOPT_WRITEFUNCTION for the new
meaning. I'm a bit curious about the 'writable' argument. What purpose does
that serve? Also, the check the callback currently does for if the buffer
is its own (SB_IN_RANGE) really can't be used like that, as that will be
really painful for the cases where the application for example decide to
keep download data in a linked list of chunks or similar. It would be much
more elegant to either have libcurl specify in the invoke if the buffer is
user-provided or libcurl-provided, or just never call this callback with
anything else than user-provided buffers.
-- Commercial curl and libcurl Technical Support: http://haxx.se/curl.htmlReceived on 2005-12-06