Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added a note on failed handles not being counted by curl_multi_perform. #4446

Closed
wants to merge 1 commit into from

Conversation

@akashihi
Copy link
Contributor

commented Oct 1, 2019

No description provided.

Copy link
Member

left a comment

Thanks for your help in improving the docs!

@@ -98,7 +98,12 @@ period for your select() calls.
one of its input arguments, and by reading that you can figure out when all
the transfers in the multi handles are done. 'done' does not mean
successful. One or more of the transfers may have failed. Tracking when this
number changes, you know when one or more transfers are done.
number changes, you know when one or more transfers are done. Please note, that
transfer may fail immediately, especially in case you are adding/re-using easy

This comment has been minimized.

Copy link
@bagder

bagder Oct 1, 2019

Member
  1. "a transfer" or "transfers" (not "transfer")
  2. Why is this likely to happen "especially" in the case you reuse handles? In my view, transfers are always roughly equally likely to fail.

This comment has been minimized.

Copy link
@akashihi

akashihi Oct 1, 2019

Author Contributor
  1. Fixed
  2. Well, you are right, fixed.
transfer may fail immediately, especially in case you are adding/re-using easy
handles into already running multi handle. At the same time newly added
transfer is not guaranteed to start immediately. In both cases
\fIcurl_multi_perform(3)\fP will not count that handle as running transfer,

This comment has been minimized.

Copy link
@bagder

bagder Oct 1, 2019

Member

This is incorrect. The number of "running handles" is increased by curl_multi_add_handle so a slow start doesn't result in a lower number. The number is however decreased when the transfer is complete, which can happen at any point and thus already in the fist call to curl_multi_perform().

This comment has been minimized.

Copy link
@akashihi

akashihi Oct 1, 2019

Author Contributor

Rephrased to be more precise.

This comment has been minimized.

Copy link
@bagder

bagder Oct 1, 2019

Member

How about instead trying to not duplicate what the curl_multi_perform.3 man page already says ? We can instead rather remove the (possibly slightly misleading) sentence "Tracking when this number changes, you know when one or more transfers are done."

This comment has been minimized.

Copy link
@akashihi

akashihi Oct 2, 2019

Author Contributor

Agree

@bagder bagder added the documentation label Oct 1, 2019
@akashihi akashihi force-pushed the akashihi:multiwaitdoc branch from a5238a0 to f96e639 Oct 1, 2019
@akashihi akashihi force-pushed the akashihi:multiwaitdoc branch from f96e639 to ebcb866 Oct 2, 2019
@bagder
bagder approved these changes Oct 3, 2019
@bagder bagder closed this in 0b38639 Oct 3, 2019
@bagder

This comment has been minimized.

Copy link
Member

commented Oct 3, 2019

Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.