Bug #63411 [Com]: curl_multi_select() returns invalid value
| From: | public-mail at alekciy dot ru | Date: | Mon, 18 May 2015 09:53:33 +0000 |
| Subject: | Bug #63411 [Com]: curl_multi_select() returns invalid value | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-192726@lists.php.net to get a copy of this message | ||
Edit report at https://bugs.php.net/bug.php?id=63411&edit=1
ID: 63411
Comment by: public-mail at alekciy dot ru
Reported by: marcel at silverstreet dot com
Summary: curl_multi_select() returns invalid value
Status: No Feedback
Type: Bug
Package: cURL related
Operating System: CentOS 6.3
PHP Version: 5.3.18
Assigned To: pierrick
Block user comment: N
Private report: N
New Comment:
I confirm to https (http OK). curl_multi_select() always and immediately return -1. Env:
test:~$ cat /etc/os-release
NAME="Ubuntu"
VERSION="14.04.2 LTS, Trusty Tahr"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 14.04.2 LTS"
VERSION_ID="14.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
test:~$ php -v
PHP 5.5.9-1ubuntu4.9 (cli) (built: Apr 17 2015 11:44:57)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies
test:~$ curl -V
curl 7.35.0 (x86_64-pc-linux-gnu) libcurl/7.35.0 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smtp
smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP
Previous Comments:
------------------------------------------------------------------------
[2013-06-05 19:40:01] yang dot phpbugs at mailnull dot com
I'm also finding this to be breaking various libraries including JAXL.
------------------------------------------------------------------------
[2013-03-13 12:14:39] quipo@php.net
What's the point of a select() call that doesn't block?
The whole point of curl_multi_select is to block until either there's some
activity on the socket, or the timeout is reached.
The curl_multi_select() call now returns immediately (with -1), without waiting
for the timeout, in all our use cases too, making it useless.
Why was the behaviour changed in the first place? Is it possible to revert?
------------------------------------------------------------------------
[2013-02-18 00:36:04] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
------------------------------------------------------------------------
[2012-12-31 23:04:18] mail+php at requinix dot net
Related To: Bug #63842
------------------------------------------------------------------------
[2012-11-15 13:54:10] pierrick@php.net
As mentioned in bug #61141, curl_multi_select() returning -1 is an expected behaviour and you should
not throw an exception which prevent your call to
be done.
Internally php curl_multi_select uses libcurl curl_multi_fdset function to set all the fd_set and
the maxfd value. The libcurl curl_multi_fdset
documentation says :
When libcurl returns -1 in max_fd, it is because libcurl currently does something that isn't
possible for your application to monitor with a socket and
unfortunately you can then not know exactly when the current action is completed using select().
When max_fd returns with -1, you need to wait a while
and then proceed and call curl_multi_perform anyway. How long to wait? I would suggest 100
milliseconds at least, but you may want to test it out in
our own particular conditions to find a suitable value.
The workaround you made is not really a workaround, but is exactly what libcurl recommend you to do
in this case :)
------------------------------------------------------------------------
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=63411
--
Edit this bug report at https://bugs.php.net/bug.php?id=63411&edit=1