curl / Mailing Lists / curl-library / Single Mail


RE: Wait for a response using curl_multi_wait

From: Cunningham, Joel <>
Date: Tue, 20 Mar 2018 22:41:59 +0000

Hi curl devs,

I just wanted to share some of the problems/solutions I've had integrating with curl_multi_wait, see response inline below.

> -----Original Message-----
> From: curl-library [] On Behalf Of
> Richard Copley
> Sent: Monday, March 19, 2018 4:05 PM
> To:
> Subject: Wait for a response using curl_multi_wait
> Hi,
> I'm posting this question a second time, although the first time it was
> apparently
> moderated as spam. Meanwhile somebody asking how to add a header to a
> request
> got through. It's confusing. I put effort into writing a good question. If there's
> something
> wrong with my question, I'd like to hear about it. Don't worry about
> offending me.
> Anyway, here's the original message again:
> Using the "multi-single.c" example[1] as a testbed, I notice that after adding
> the easy handle and calling curl_multi_perform, the curl_multi_wait call
> returns immediately and sets numfds to 0, indicating there is no fd to wait
> on.
> Question: Isn't there a socket fd to wait on for the connect() and/or the
> data?
> In the "multi-single.c" example, there is a Sleep() in the main loop. If the
> sleep interval is too small then we use too much CPU in going round the loop.
> If the interval is too big, we risk reacting too slowly when the response
> arrives. A 50ms to 100ms sleep interval is probably Just Right, but if possible,
> it would be neater to avoid the Sleep() altogether and wait (one or more
> times) for something to happen.
> Question: Is it possible?

curl_multi_wait() has been particularly hard to integrate with in a manner which doesn’t unnecessarily sleep and end up in a tight loop. What I’ve found is the main issue is a lack of information about if any waiting was actually done.

Here are some of the cases I’ve found, which can’t be distinguished between from the function output:

1) Multi handle has no valid FDs and did not wait the requested timeout.
2) Multi handle has valid FDs, but did no work on them, AND did not wait the requested timeout (seen this with CURLOPT_MAX_RECV_SPEED_LARGE).
3) Multi handle has valid FDs and waited the entire timeout, no FDs are ready.

All of these set numfds to 0, so the application code has no choice but to guess at which case happened.

The current solutions I’ve come up with are:

1) Add a dummy FD as an extra FD so that curl_multi_wait() always calls select()/poll() and waits the provided timeout.
2) Record the amount of time spent in curl_multi_wait and if numfds is 0, make sure the entire timeout was waited, if not, do an extra wait before curl_multi_perform

> I tried the sample on Windows 10 with libcurl 7.57.0 built by the MSYS2
> project for native Windows (i.e., not relying on Cygwin or MSYS for POSIX
> emulation) and on Ubuntu 17.10 using libcurl 7.55.1 from the Ubuntu package
> sources (package libcurl4-openssl-dev). Same results on both.
> Big thanks to Daniel and everyone who has worked on libcurl. It's a pleasure
> to use and the documentation is outstandingly good.
> [1]

I'm curious if anyone else has other ideas for better dealing with this issue or if there is any interest in updating curl_multi_wait to indicate when it did not wait.


Received on 2018-03-20