Daniel Stenberg wrote:
> Doesn't the CURLFORM_BUFFER already offer this feature more or less?

Yes, and I tried to indicate that in my initial message. Libcurl
definitely provides the support I need to do this myself; I was just
wondering if it would be considered a worthwhile enhancement to fold it
in. Not that I'm sure I'd have time to do so.

BTW, I'm a little confused about the differences between
CURLFORM_BUFFER* and CURLFORM_PTR*. I'm currently using
CURLFORM_PTRNAME, CURLFORM_PTRCONTENTS, and CURLFORM_CONTENTSLENGTH and
it seems to be working fine. What's the difference between that and
CURLFORM_BUFFER/CURLFORM_BUFFERPTR/CURLFORM_BUFFERLENGTH?

> Sure, _you_ need to do the mmap() and not libcurl but still...

And the unmap which is the slightly trickier (but still solvable) part.

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

True. I'm sure it's impossible to characterize the tradeoff completely
and platform independently.

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

Unlikely, except perhaps for very large files. The larger win is data
integrity; by providing a buffer plus a size, the transfer is protected
against data being appended to the file during the upload. The speed
issue is somewhat tangential; I'm currently doing synchronous transfers
using the easy API which are slowing things down quite a bit. I'm trying
to convert to async transfers using the multi API but by not waiting for
the upload to complete, a window is open for someone (OK, my own code)
to append to the file before the transfer completes. Thus, at least in
my case, though mmap may not have much direct performance impact it
enables a more aggressive optimization (async transfers).

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

Ah, I hadn't understood this. Thanks.

MB
Received on 2006-08-22