On Wed, 28 Sep 2011, Julien wrote:

>> In general, libcurl won't care for how fast or slow you actually send the
>> file. Once the transfer has started, libcurl will just sit waiting for more
>> data. If you send data slowly, then libcurl will receive it slowly.
>
> You mean that I just have to block in the read callback until some more data
> is available? Do you confirm that I have to dedicate a thread to this?

When you're downloading data, there won't be any read callback called. libcurl
will just read from the socket (network data stream) and deliver data to the
write callback as soon as there is data to deliver. So yes, libcurl will sit
waiting for data until data arrives. Then act and then go back to waiting.
Until done.

You probably want that in a separate thread, yes, if you plan on doing other
things simultaneously while waiting for the slow download.

Or you switch to use the multi interface, as then you can do your own
application's I/O muxed with the libcurl network traffic in a single select().
But that then of course depends on what exactly your main loop looks like etc.

>>> I looked on CURL_WRITEFUNC_PAUSE and curl_easy_pause but I am not sure how
>>> to use these features for my use case.
>>
>> I don't think you should use that feature at all. Just let the transfer be
>> slow.
>
> Out of interest, for what kind of use case is this feature useful?

For example when your local side can't keep up with the data rate that the
other side delivers, and you want to slow it down - without sleeping in the
write callback. I would say it is most usable with the multi interface when
you have multiple transfers going as then you don't want either one block any
other transfer.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html