Dan Fandrich wrote:
> On Mon, Aug 21, 2006 at 10:35:34PM -0400, Mohun Biswas wrote:
>> I've also thought of sprintf-ing these pairs into strings, making a list
>> of them with curl_slist_append(), then storing the slist in the handle
>> using CURLOPT_PRIVATE. Unfortunatelythere's no documented way of
>> traversing an slist.
>
> Why bother with slists if you're just going to use it with CURLOPT_PRIVATE,
> the contents of which curl happily ignores? Just create your own struct
> containing file descriptor, mmap pointer, etc. and set that with
> CURLOPT_PRIVATE.

Yes, I'm aware that I may have to implement much of this myself - I'm
just trying to do as much as possible within the infrastructure provided
by libcurl. In answer to your specific question, I can't simply allocate
a struct because there may be multiple file parts, so I need a list of
structs and was hoping to use the list API provided by curl for this
purpose.

I guess one related question would be, is there a case for enhancing
libcurl to work like this routinely? In other words change CURLFORM_FILE
such that it maps the file rather than setting up a callback, then
unmaps it at tear-down (curl_formfree) time? My understanding is that
mapping is generally faster at least for files of a certain size. Google
shows Linus Torvalds saying

"The gcc people tested it [mmap], and their cut-off point is at 30kB or
so. Anything smaller than that is faster to just read()".
(http://www.ussg.iu.edu/hypermail/linux/kernel/0110.1/1601.htm).

FWIW, here's what I was thinking of doing in my own code: (a) open the
file, (b) fstat it, (c) if it's bigger than some configurable size mmap
it, otherwise malloc a sufficient chunk of memory and read() the entire
file in, (d) close the file descriptor. Then store two values (pointer
and size) in a struct. At tear-down time, if size==0 that means we
malloc-ed; free the pointer. If size > 0, munmap(pointer,size). If there
was a public API for traversing slists I'd probably use asprintf to
squeeze these two values into a "pointer.size" string for convenience.

MB
Received on 2006-08-22