On Wed, 3 Sep 2014, Saikrishna Bhagavatula wrote:

> It is my understanding that setting curl_easy_setopt() options only take
> effect for subsequent transfers and will not have any effect on an ongoing
> transfer.

That's not exactly true and it's not exactly what is documented.

We say that you should set the settings before you start the transfers as
that's what we "guarantee" works and we have tests for most options used like
this. That way we know they work.

You can set a lot of the options during an ongoing transfer as well and most
will take an immediate effect. Some of them might unfortunately have an
immediate negative effect when set because they weren't really designed to be
modified in the middle.

> Is there a way to update some options so that they take immediate effect on
> an ongoing transfer ? If not, can we modify libcurl to do this?

So, it is indeed possible and in most cases it isn't really necessary to
change anything in the code. What we need to change is A) do test cases that
run such scenarios and B) document which options you can set during run-time
and possibly what effect they have when used in that way.

> We would like to change the CURLOPT_LOW_SPEED_TIME at some points during the
> transfer (like after the initial 100-Continue header). Some of these delays
> in writing can be predicted and we do not want the transfer to be aborted in
> such cases. So we either want to disable the CURLOPT_LOW_SPEED_TIME and
> enable it later or set a larger value and change it later.

I think CURLOPT_LOW_SPEED_TIME is a perfect example of a setting that might
leave libcurl in a funny state if modified (a lot) during run-time if you hit
it at an unfortunate point in time. But also I haven't really analyzed this...

It is also a fairly easy feature to implement on your own (outside of libcurl)
and just stop the transfer on that handle when you think it is too slow.

> What do you think of a curl_easy_setopt_immediate() which can take some curl
> options which can be changed during a transfer. This will really be useful
> for long duration transfers (In our case, even the GET transfers take very
> long - several hours).

I don't think we need another function for that, I think we should use the
same function but make sure that the updated value is handled appropriately.

> Also, wouldn't it be better if CURLOPT_LOW_SPEED_TIME does not come into
> effect for PAUSED transfers?

Yeah I guess so, but that would greatly complicate the math used to figure out
the transfer speed. I'm not sure it's really worth the trouble.

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