cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: mmap & file uploads

From: Sterling Hughes <sterling_at_designmultimedia.com>
Date: Wed, 30 May 2001 05:54:45 -0400

Daniel Stenberg wrote:

> On Wed, 30 May 2001, Sterling Hughes wrote:
>
>
>>>I can see that there's gonna be an extra copy operation that could be avoided
>>>if we offer a different set of arguments to the callback function (which
>>>indeed can be discussed).
>>>
>>>Is that what we should discuss?
>>>
>>yep, it would be nice if this could be changed...
>>
>
> [re-iterating the subject a little]
>
> In cases where the application will still have the contents of the file even
> efter the callback function is returned, there is no point in copying the
> data to libcurl's internal buffer only to write it to the network layer the
> next moment.
>
> We could still offer the current read callback for old times sake and for all
> those cases where the above statement is not true.
>
> It could possibly look like this:
>
> size_t read_file(void *clientp, size_t size, unsigned char **bufptr);
>
> An application would then:
>
> 1 - use the clientp for whatever purpose it feels like
>
> 2 - set the *bufptr to point to the start of the buffer piece to upload next
>
> 3 - return 'size' or less bytes (the reason for this maximum amount is
> merely for blocking purposes, so that we don't write to write X*1000
> bytes to a socket when we only do X*10 bytes per second, as that would
> make a very long block with bad a lousy progress meter as result among
> other things)
>
> Thoughts?
>

Looks good. Is there any reason to have 'unsigned char *' instead of
'void *' or 'char *' here?

-Sterling

-- 
Sterling Hughes
sterling_at_designmultimedia.com
http://www.designmultimedia.com/
_______________________________________________
Curl-library mailing list
Curl-library_at_lists.sourceforge.net
http://lists.sourceforge.net/lists/listinfo/curl-library
Received on 2001-05-31