]> git.ipfire.org Git - thirdparty/curl.git/commitdiff
CURLMOPT_MAX*: mention what happens if changed mid-transfer
authorDaniel Stenberg <daniel@haxx.se>
Fri, 22 Mar 2024 23:36:50 +0000 (00:36 +0100)
committerDaniel Stenberg <daniel@haxx.se>
Sat, 23 Mar 2024 10:31:36 +0000 (11:31 +0100)
For CURLMOPT_MAXCONNECTS and CURLMOPT_MAX_HOST_CONNECTIONS

Ref: #13158
Closes #13176

docs/libcurl/opts/CURLMOPT_MAXCONNECTS.md
docs/libcurl/opts/CURLMOPT_MAX_HOST_CONNECTIONS.md

index 0a7eb4965dd633c0c99fdf48f66ce070b3a6f07c..317eea6d01baac4b3b019d07d82b61a219cf2cbc 100644 (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
index ceb8850ed3e85cbc944b45f45a1205c7b53b5bcd..099efddc5cc63371b6776be8588eee50cfb4881a 100644 (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