conncache: only allow multiplexing within same multi handle

Connections that are used for HTTP/1.1 Pipelining or HTTP/2 multiplexing
only get additional transfers added to them if the existing connection
is held by the same multi or easy handle. libcurl does not support doing
HTTP/2 streams in different threads using a shared connection.

Closes #2152
This commit is contained in:
Daniel Stenberg 2017-12-05 08:39:31 +01:00
parent 415b8dff8e
commit ea3a5d07dc
No known key found for this signature in database
GPG key ID: 5CC908FDB71E12C2
2 changed files with 14 additions and 2 deletions

View file

@ -75,8 +75,15 @@ Put the connection cache in the share object and make all easy handles using
this share object share the connection cache. Using this, you can for example
do multi-threaded libcurl use with one handle in each thread, and yet have a
shared pool of unused connections and this way get way better connection
re-use than if you use one separate pool in each thread. Support for this was
added in 7.57.0, but the symbol existed long before this.
re-use than if you use one separate pool in each thread.
Connections that are used for HTTP/1.1 Pipelining or HTTP/2 multiplexing only
get additional transfers added to them if the existing connection is held by
the same multi or easy handle. libcurl does not support doing HTTP/2 streams
in different threads using a shared connection.
Support for \fBCURL_LOCK_DATA_CONNECT\fP was added in 7.57.0, but the symbol
existed before this.
.RE
.IP CURLSHOPT_UNSHARE
This option does the opposite of \fICURLSHOPT_SHARE\fP. It specifies that