mirror of
https://github.com/curl/curl.git
synced 2025-02-23 15:10:03 +08:00
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:
parent
c5775007d3
commit
7bc61bf469
@ -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
|
||||
|
@ -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
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user