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.

curl_multi_poll: a sister to curl_multi_wait() that waits more

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

Hi team,

Very soon after we introduced curl_multi_wait() I realized it had an awkward
behavior that makes it tricky to use at times. Today I wrote up an initial
proposal for a drop-in function replacement that probably is more what
application authors actually want and need - and some probably already thought
curl_multi_wait() worked like this.

I'm open for all and any feedback! Nothing in this is written in stone yet...

See the relatively small patch in PR 4163:


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.

This is often missed or misunderstood, leading to underperforming

This change introduces curl_multi_poll() as a replacement drop-in
function that accepts the exact same set of arguments. This function
works identically to curl_multi_wait() - EXCEPT - for the case when
there's nothing to wait for internally, as then this function will by
itself wait for a "suitable" short time before it returns. This
effectiely avoids all risks of busy-looping and should also make it less
likely that apps "over-wait".

This also changes the curl tool to use this funtion internally when
doing parallel transfers and changes curl_easy_perform() to use it

  / | Get the best commercial curl support there is - from me
                   | Private help, bug fixes, support, ports, new features
Received on 2019-07-29