Issue 55 curl multirunner burn cpu

[mekras]

No description provided.

[dbu]

thank you for looking into this. some comments and questions:

[dbu]

please don't revert yoda style comparisons.

[mekras]

Why?

[dbu]

because it has nothing to do with the change at hand.

i would have expected the code style checker to complain, but seems we don't have a rule for this activated.

[dbu]

is this now again busy waiting? should we repeat the curl_multi_select in each loop?

[mekras]

I'm not pretty sure. Most examples I've found are like this https://bugs.php.net/bug.php?id=61141#1348321490

[dbu]

its again the same as guzzle does, which is most likely what the symfony http client is using, so i'd hope its the right thing.

[ricostone]

Hi i'm running into this, any merge planned ? Any help needed ?
We actually kickfixed like this ...

$status = curl_multi_exec($this->multiHandle, $active);
$info = curl_multi_info_read($this->multiHandle);
if (false !== $info) {
                ...
}else{
 // fixing issue https://github.com/php-http/curl-client/issues/55
 usleep(self::MULTI_RUNNER_USLEEP);
}

[dbu]

from elastic/elasticsearch-php#990:

a solution proposed at https://bugs.php.net/bug.php?id=61141#1348321490 is

while ($active && $mrc == CURLM_OK) {
    if (curl_multi_select($mh) == -1) usleep(100);
    do { $mrc = curl_multi_exec($mh, $active); }
    while ($mrc == CURLM_CALL_MULTI_PERFORM);
}

(which we should format according to our code style, but functionality seems good to me. 100 micro seconds is 1 thousandst of a second, so should be an acceptable delay while lowering the cpu)