|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #23838 stream_select() not functioning properly
Submitted: 2003-05-27 12:57 UTC Modified: 2003-06-02 17:28 UTC
Avg. Score:3.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:0 (0.0%)
From: dietrich dot ayala at foundstone dot com Assigned: wez (profile)
Status: No Feedback Package: Sockets related
PHP Version: 4.3.2RC4 OS: windows 2000
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: dietrich dot ayala at foundstone dot com
New email:
PHP Version: OS:


 [2003-05-27 12:57 UTC] dietrich dot ayala at foundstone dot com
1. it doesn't seem to be doing non-busy waits. If the remote host takes a long time to respond, the CPU is still maxed until a response is received.

2. I've had repeatable situations where the server returned a response right away, but stream_select() didn't return for (in our repeatable case) 10 mins. What's it's criteria for responding? What will it do if I pass a stream to it, which has already had everything read from it, but is persistent, so there's no EOF/line-break/anything? It seems that whatever its return criteria is, it isn't met sometimes.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2003-05-27 14:48 UTC]
Assigning to myself; it would be good if some other people could verify if this problem exists on other platforms, and if this is a critical issue.

 [2003-05-27 17:15 UTC]
Can not reproduce on Linux. (no script to test with)
Not really critical, it's just some streams thingie. :)
 [2003-05-27 17:35 UTC] dietrich dot ayala at foundstone dot com
"cannot reproduce" is different from "didn't attempt to reproduce" ;)

Also, this is very critical! PHP doesn't look so good when even the smallest network activity could bring the box to a crawl if anything besides PHP is active. This is especially frustrating when the server is localhost, so you have all your progs having to battle PHP for CPU, and PHP doesn't even need it, except to busy-wait!

Here's the repro script. This brings CPU to 100% every time on my win2k box. I set up a server that sleeps for a few seconds before responding, and that showed it even more clearly than  this example.


$host = 'd-w2kserv';
$port = 80;

// open connection
if(!$fp = pfsockopen($host, $port, $errno, $error_str)){
	die('error: '.$error_str.$phperrormsg);
} else {

	// write data
	$requestMsg = "GET / HTTP/1.1\r\nHost: $host\r\n\r\n";
	if(!@fwrite($fp, $requestMsg)) {
		die('error: '.$phperrormsg);
	// read data
	do {
		// array of connections
		$read = array($fp);
		// use stream_select() for non-busy wait
		if (false === ($num_changed_streams = stream_select($read, $write = NULL, $except = NULL, 0))) {
		   die('Stream_select returned error: '.$phperrormsg);
		// At least on one of the streams something interesting happened 
		} elseif ($num_changed_streams > 0) {
			if( !$data = @fgets($fp, 8192) ){
				die('couldnt get data from socket, or socket returned no data');
			print $data;
			// no more data
			if (feof($fp) || $data === false || strlen($data) == 0) {

	} while(true);
 [2003-05-27 18:01 UTC]
Try using a non-zero timeout value in the stream_select() call.  Zero means return immediately if there is no data, so it will definitely eat CPU that way.
 [2003-06-02 17:28 UTC]
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.

PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun Jul 14 08:01:28 2024 UTC