curl / Mailing Lists / curl-library / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

Re: curl_multi_poll: a sister to curl_multi_wait() that waits more

From: Christopher Head via curl-library <>
Date: Tue, 30 Jul 2019 08:41:09 -0700

On Mon, 29 Jul 2019 13:54:07 +0200 (CEST)
Daniel Stenberg via curl-library <> wrote:

> Repeatedly we see problems where using curl_multi_wait() is difficult
> or just awkward because if it has no file descriptor to wait for
> internally, it returns immediately and leaves it to the caller to wait
> for a small amount of time in order to avoid occasional busy-looping.

I may have been one of the people who misunderstood that. When I saw
the sentence, “If no extra file descriptors are provided and libcurl
has no file descriptor to offer to wait for, this function will return
immediately,” in the documentation, I originally thought this meant if
there are no easy handles in the multi handle, but I see now that it
actually might also mean it returns immediately if there are easy
handles in the multi handle that are carrying out transfers, but none
of them actually want their FD to be selected on right now.

I was wondering what the implications were for
CURLOPT_MAX_RECV_SPEED_LARGE? That is described as “If a download
exceeds this speed… the transfer will pause,” but from inspecting the
code, I do not think the word “pause” here refers to “curl_easy_pause.”
I think it actually means an internal-to-libcurl delay, after which the
easy handle automatically continues transferring data (as an aside, I
think this might be worth rewording in the documentation, if my
interpretation is correct that it is not related to curl_easy_pause).
What I *expected* to happen is that, if the receive rate is too high,
curl will stop calling recv() for a little while, and that “little
while” will be implemented by curl_multi_wait not selecting for
readability on the FD, but instead treating it like any other time
delay or timeout requested by an easy handle (i.e. curl_multi_wait
clamps the user-specified timeout_ms value to the minimum of the
timeouts requested by all contained easy handles, including timeouts
for throttling purposes). But if I now understand correctly, with no
FDs selectable, curl_multi_wait will return immediately; does this
include if all easy handles are throttling? How do I know that this
happened, so that I know I have to sleep outside curl_multi_wait rather
than just carrying on immediately?

Christopher Head


Received on 2019-07-30