On Tue, 22 Aug 2006, Mohun Biswas wrote:

> 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?

Doesn't the CURLFORM_BUFFER already offer this feature more or less? Sure,
_you_ need to do the mmap() and not libcurl but still...

> My understanding is that mapping is generally faster at least for files of a
> certain size.

... on certain operating systems.

> 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).

Is the speed difference between doing mmap() and reading the file in chunks
into a buffer really that significant?

> 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.

Well, slists in libcurl's world are curl_lists and they are public structs.
You can traverse them all you want.

In curl_formadd()'s case the struct curl_httppost is also public and
available. You can traverse that all you want. You don't *need* to use
curl_formadd(), you can build your own chain of curl_httppost structs and pass
to libcurl.

-- 
  Commercial curl and libcurl Technical Support: http://haxx.se/curl.html