CURLMOPT_MAX*: mention what happens if changed mid-transfer

For CURLMOPT_MAXCONNECTS and CURLMOPT_MAX_HOST_CONNECTIONS

Ref: #13158
Closes #13176
This commit is contained in:
Daniel Stenberg 2024-03-23 00:36:50 +01:00
parent c5775007d3
commit 7bc61bf469
No known key found for this signature in database
GPG Key ID: 5CC908FDB71E12C2
2 changed files with 18 additions and 8 deletions

View File

@ -43,6 +43,11 @@ you should instead use the CURLOPT_MAXCONNECTS(3) option.
See CURLMOPT_MAX_TOTAL_CONNECTIONS(3) for limiting the number of active
connections.
Changing this value when there are transfers in progress is possible, and the
new value is then used the next time checks are performed. Lowering the value
does however not close down any active transfers, it simply does not allow new
ones to get made.
# DEFAULT
See DESCRIPTION

View File

@ -29,9 +29,9 @@ CURLMcode curl_multi_setopt(CURLM *handle, CURLMOPT_MAX_HOST_CONNECTIONS,
Pass a long to indicate **max**. The set number is used as the maximum amount
of simultaneously open connections to a single host (a host being the same as
a hostname + port number pair). For each new session to a host, libcurl might
open a new connection up to the limit set by
CURLMOPT_MAX_HOST_CONNECTIONS(3). When the limit is reached, new sessions are
kept pending until a connection becomes available.
open a new connection up to the limit set by CURLMOPT_MAX_HOST_CONNECTIONS(3).
When the limit is reached, new sessions are kept pending until a connection
becomes available.
The default **max** value is 0, unlimited. This set limit is also used for
proxy connections, and then the proxy is considered to be the host for which
@ -39,12 +39,17 @@ this limit counts.
When more transfers are added to the multi handle than what can be performed
due to the set limit, they are queued up waiting for their chance. When that
happens, the CURLOPT_TIMEOUT_MS(3) timeout is inclusive of the waiting
time, meaning that if you set a too narrow timeout in such a case the transfer
might never even start before it times out.
happens, the CURLOPT_TIMEOUT_MS(3) timeout is inclusive of the waiting time,
meaning that if you set a too narrow timeout in such a case the transfer might
never even start before it times out.
Even in the queued up situation, the CURLOPT_CONNECTTIMEOUT_MS(3)
timeout is however treated as a per-connect timeout.
Even in the queued up situation, the CURLOPT_CONNECTTIMEOUT_MS(3) timeout is
however treated as a per-connect timeout.
Changing this value when there are transfers in progress is possible, and the
new value is then used the next time checks are performed. Lowering the value
does however not close down any active transfers, it simply does not allow new
ones to get made.
# DEFAULT