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

On Tue, 30 Jul 2019, Christopher Head via curl-library wrote:

> 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.

Yes correct, that is exactly what it means. If you can think of a way to say
that in a way that is clearer to the reader, please suggest!

> 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

That is exactly what happens. The application just sets the option and then it
makes the transfer just like normally and libcurl will internalls do short
pauses when it has to in order to keep the transfer speed below the specified
limit. When a transfer is determined to have been over the limit and it needs
to wait a little to have it cool down, the socket is removed from the set of
sockets to wait for...

> (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).

I hear you. I never thought about it that way! Maybe avoid the word "pause"
there and just say "slow down" or something?

> if I now understand correctly, with no FDs selectable, curl_multi_wait will
> return immediately; does this include if all easy handles are throttling?

Yes

> 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?

It's difficult as there's no clear indication it happens. Like there's no
return code or state that tells us this. Which of course is one reason why I
propose this new API so that we can have this sorted out.

One way I've used myself is simply have it time-based. If the function returns
(repeatedly a few times) within N milliseconds and reports no sockets to wait
for, call curl_multi_timeout() to get a suitable timeout and simply sleep for
that many milliseconds.

-- 
  / daniel.haxx.se | Get the best commercial curl support there is - from me
                   | Private help, bug fixes, support, ports, new features
                   | https://www.wolfssl.com/contact/

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2019-07-30