cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Info request about the zero copy interface (2)

From: Legolas <legolas558_at_email.it>
Date: Mon, 05 Dec 2005 15:25:50 +0100

Jamie Lokier ha scritto:

>Legolas wrote:
>
>
>>>Legolas' pattern requires each decompressed data chunk to be then
>>>_copied_, from the algorithm's 32k buffer, to the application's
>>>supplied buffer. That is more copies than necessary.
>>>
>>>
>>>
>>No, the library is aware of a destination buffer and can write to it.
>>Again, give a look at the pseudo-code in the previous reply please.
>>
>>
>
>You mean this part? :
>
>
>>MainLoop:
>> received_size = recv(yoursocket, internal_buffer, internal_buffer_size, yourflags);
>> buffer_size = forecast_size(received_size);
>> /* forecast someway by libcurl */
>> buffer = write_buffer(custom_data, &buffer_size);
>> /* application may return a bigger buffer */
>> ... (decode SSL, join chunks...)
>> /* work on received data putting final result data into 'buffer' */
>> write_callback(custom_data, final_size);
>> /* previous code must set 'final_size' to the size of data written to 'buffer' */
>>
>>The line followed by the comment "work on received data putting final
>>result data into 'buffer'" copies data into 'buffer'. That copy is
>>not necessary. In what way is this doing "zero-copy"?
>>
Does not copy! I have used the verb _putting_, i.e. each final result
byte or block is written directly to the 'buffer' by the algorithm
intended to be in place of the ellipsis (...). Overall, there is no copy
at the end of the work process (otherwise I would have expressely
pointed out it).

In the hypothesis that this buffer interface is adaptable to the used
algorithms, there would be at least ONE copy less this way...however I
am just trying to draw up a scheme. I am also giving attention to your
previous reply: your points a,b,c,d,e are of course to be implemented,
but I can't figure out the case (e) ...
Received on 2005-12-05