curl_multi_select can return immediately ignoring timeout, with result 0 and error code 0

[TysonAndre]

Guzzle version(s) affected: unknown

Description
The implementation of curl_multi_select changed in PHP 7.1.23/7.2.11 - It uses curl_multi_wait instead of curl_multi_select. See https://bugs.php.net/bug.php?id=76480

When this happens, requests will typically succeed, but spike to 100% cpu while waiting for requests to complete (because nothing is sleeping, not even curl_multi_select)

• It might be possible that some settings in Guzzle prevent this, but unlikely.
• This issue being filed may be related to issues reported after 2018-09

How to reproduce
This may only affect php >= 7.1.23 and curl >= 7.28.0. Use getAsync methods, where one endpoint takes a long time to respond (and another has a connect timeout). You may have to run this test repeatedly and log the number of times curl_multi_exec gets called.

Possible Solution
Call usleep(250 microseconds - microseconds elapsed since previous call to curl_multi_select ended) if curl_multi_select returns <= 0? A proposed fix to a different library is WordPress/Requests#284 - The symptoms seen prior to this is https://gist.github.com/TysonAndre/46a6829d9d8de00e50226890a6a9a63f (both curl_multi_select and curl_multi_exec return 0 but many times don't respect the configured timeout of 50 milliseconds)

• It already sleeps for a return value of -1.

Additional context
I observed that repeatedly calling curl_multi_select and curl_multi_exec

The guzzle implementation using curl_multi_select without handling a return value of 0 is:

https://github.com/guzzle/guzzle/blob/8f10d0e/src/Handler/CurlMultiHandler.php#L117-L130

[Nyholm]

Hey. Thank you for the bug report.

I've made the patch you suggested. Could you please try if it works?

#2393

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 2 weeks if no further activity occurs. Thank you for your contributions.