Doc #63842 [Nab]: Infinite loop in example code
| From: | googleguy@php.net | Date: | Wed, 16 Jan 2013 18:31:56 +0000 |
| Subject: | Doc #63842 [Nab]: Infinite loop in example code | ||
| References: | 1 | Groups: | php.doc.bugs |
| Request: | Send a blank email to doc-bugs+get-9430@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=63842&edit=1
ID: 63842
Updated by: googleguy@php.net
Reported by: dean at ovts dot com dot au
Summary: Infinite loop in example code
Status: Not a bug
Type: Documentation Problem
Package: Documentation problem
PHP Version: Irrelevant
Block user comment: N
Private report: N
New Comment:
*Correction to my last comment
"This is not a bug, because the condition of the loop is NOT dependent upon
curl_multi_select."
Previous Comments:
------------------------------------------------------------------------
[2013-01-16 18:31:05] googleguy@php.net
This is not a bug, because the condition of the loop is dependent upon
curl_multi_select. If the curl_multi_select returns -1 the code within the loop
body is simply not executed. This still does not create an infinite loop under
normal conditions because eventually if all of the curl handles timeout they are
freed from the select resource handle.
------------------------------------------------------------------------
[2013-01-16 15:05:07] googleguy@php.net
Related To: Bug #63936
------------------------------------------------------------------------
[2013-01-03 15:09:09] dean at ovts dot com dot au
Whoops... I meant to change all the $curlMH variables to $mh to match the previous code snippet, but
I only did the first one. So '$curlMH' in the above code should actually be
'$mh'. Sorry about that!
------------------------------------------------------------------------
[2013-01-03 15:05:11] dean at ovts dot com dot au
That would certainly fix the inifinite loop problem.
I'm not clear on why you'd need to wait 100ms (or some other arbitrary amount of time)
before calling curl_multi_exec again... this just seems like bad design to me (even if the libcurl
docs recommend it). How many times might you end up doing this 100ms sleep? The whole point of
curl_multi_select is to sleep exactly the minimum amount, and wake up as soon as some curl operation
is ready to continue.
What would happen if you simply ignored the return value of curl_multi_select, and did this:
while (curl_multi_exec($mh, $active) === CURLM_CALL_MULTI_PERFORM);
do
{
curl_multi_select($curlMH);
while (curl_multi_exec($curlMH, $active) === CURLM_CALL_MULTI_PERFORM);
} while ($active);
(Also, do we need to break if curl_multi_exec doesn't return CURLM_OK, or can we just keep
going until $active is false, as I've done above? What would it mean if $active were true, but
the return value wasn't CURLM_OK?)
------------------------------------------------------------------------
[2012-12-31 23:04:18] mail+php at requinix dot net
curl_multi_init()'s example has the same problem. Given the history of the
underlying bug (see bug #63411, bug #61141) I'm hesitant to just go in and
submit a change.
In the comments for 61141 are two code bits that should work, the preferred one
(from pierrick) being
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);
}
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=63842
--
Edit this bug report at https://bugs.php.net/bug.php?id=63842&edit=1