4c35574bb7
Fixes #3436 Closes #3448 Problem 1 After LOTS of scratching my head, I eventually realized that even when doing 10 uploads in parallel, sometimes the socket callback to the application that tells it what to wait for on the socket, looked like it would reflect the status of just the single transfer that just changed state. Digging into the code revealed that this was indeed the truth. When multiple transfers are using the same connection, the application did not correctly get the *combined* flags for all transfers which then could make it switch to READ (only) when in fact most transfers wanted to get told when the socket was WRITEABLE. Problem 1b A separate but related regression had also been introduced by me when I cleared connection/transfer association better a while ago, as now the logic couldn't find the connection and see if that was marked as used by more transfers and then it would also prematurely remove the socket from the socket hash table even in times other transfers were still using it! Fix 1 Make sure that each socket stored in the socket hash has a "combined" action field of what to ask the application to wait for, that is potentially the ORed action of multiple parallel transfers. And remove that socket hash entry only if there are no transfers left using it. Problem 2 The socket hash entry stored an association to a single transfer using that socket - and when curl_multi_socket_action() was called to tell libcurl about activities on that specific socket only that transfer was "handled". This was WRONG, as a single socket/connection can be used by numerous parallel transfers and not necessarily a single one. Fix 2 We now store a list of handles in the socket hashtable entry and when libcurl is told there's traffic for a particular socket, it now iterates over all known transfers using that single socket. |
||
---|---|---|
.github | ||
CMake | ||
docs | ||
include | ||
lib | ||
m4 | ||
packages | ||
projects | ||
scripts | ||
src | ||
tests | ||
winbuild | ||
.dir-locals.el | ||
.gitattributes | ||
.gitignore | ||
.lgtm.yml | ||
.mailmap | ||
.travis-iconv-env.sh | ||
.travis.yml | ||
acinclude.m4 | ||
appveyor.yml | ||
buildconf | ||
buildconf.bat | ||
CHANGES | ||
CMakeLists.txt | ||
configure.ac | ||
COPYING | ||
curl-config.in | ||
GIT-INFO | ||
libcurl.pc.in | ||
MacOSX-Framework | ||
Makefile.am | ||
Makefile.dist | ||
maketgz | ||
README | ||
README.md | ||
RELEASE-NOTES |
Curl is a command-line tool for transferring data specified with URL syntax. Find out how to use curl by reading the curl.1 man page or the MANUAL document. Find out how to install Curl by reading the INSTALL document.
libcurl is the library curl is using to do its job. It is readily available to be used by your software. Read the libcurl.3 man page to learn how!
You find answers to the most frequent questions we get in the FAQ document.
Study the COPYING file for distribution terms and similar. If you distribute curl binaries or other binaries that involve libcurl, you might enjoy the LICENSE-MIXING document.
Contact
If you have problems, questions, ideas or suggestions, please contact us by posting to a suitable mailing list.
All contributors to the project are listed in the THANKS document.
Website
Visit the curl web site for the latest news and downloads.
Git
To download the very latest source from the Git server do this:
git clone https://github.com/curl/curl.git
(you'll get a directory named curl created, filled with the source code)
Notice
Curl contains pieces of source code that is Copyright (c) 1998, 1999 Kungliga Tekniska Högskolan. This notice is included here to comply with the distribution terms.
Backers
Thank you to all our backers! 🙏 [Become a backer]
Sponsors
Support this project by becoming a sponsor. Your logo will show up here with a link to your website. [Become a sponsor]