php.net |  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
Votes:1
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
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
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.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-05-27 14:48 UTC] wez@php.net
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] sniper@php.net
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.

<?php

$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) {
				break;
			}

		}
		
	} while(true);
}
?>
 [2003-05-27 18:01 UTC] wez@php.net
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] sniper@php.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.


 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Dec 21 14:01:32 2024 UTC