php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #25575 stream_set_blocking with STDIN doesnt block
Submitted: 2003-09-17 11:13 UTC Modified: 2004-01-19 14:11 UTC
Votes:3
Avg. Score:5.0 ± 0.0
Reproduced:3 of 3 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (33.3%)
From: bill at baghead dot co dot uk Assigned: wez (profile)
Status: No Feedback Package: Sockets related
PHP Version: 4CVS-2003-12-16 OS: Redhat 9
Private report: No CVE-ID: None
View Developer Edit
 [2003-09-17 11:13 UTC] bill at baghead dot co dot uk 
Description:
------------
Hi,

When using xinetd with a php script - then using php to read from the "socket" with STDIN / STDOUT, as thats how xinetd translates sockets. I find that setting blocking on the socket like the code below, I find the while loops and uses all my cpu time - whereas the fread should block, and wait till it gets something..

If I uncomment the sleep line - it drops down the cpu usage, but I would rather have the blocking working.

The process function processes the data, and is irrelevant here.

PHP Was compiled with:
./configure --enable-cli --with-sockets --with-openssl --with-curl --enable-pcntl --enable-sigchild --with-mysql --enable-sockets

Made with:
 C_INCLUDE_PATH=/usr/kerberos/include make

Version:
PHP 4.3.4-dev (cli) (built: Sep 17 2003 16:04:24)



Reproduce code:
---------------
<?php
set_time_limit (0);
ob_implicit_flush ();
stream_set_blocking(STDIN,TRUE);
$read = array(STDIN);

while (true) {
	$buf = fread(STDIN,128);
	//if ($buf == "") { sleep(1); }
	process($buf);
	unset($buf);
}
?>

Expected result:
----------------
For the fread to block and wait for input, rather than return immediately.

Actual result:
--------------
The fread returns (even with no data), and loops.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-09-17 11:57 UTC] wez@php.net 
The default mode for streams is blocking mode, so you shouldn't need to call this function at all.

Is xinetd setting it to non-blocking before the script starts?

It does sound like you have a bug there, I just thought you might like to try a workaround until it gets fixed.
 [2003-09-17 12:49 UTC] bill at baghead dot co dot uk 
Surely it wouldnt matter if xinetd opened the socket blocking or non-blocking, as the script opens STDIN which needs to be blocking.... as php is talking to stdin, *not* the socket directly..
 [2003-09-17 13:14 UTC] wez@php.net 
Will you please try the workaround I suggested?
I'm not saying it isn't a bug, I'm just suggesting something that might help get your script working in the time it takes for this bug to get fixed.
 [2003-09-17 18:35 UTC] wez@php.net 
Comment sent from user by mail;
please don't mail people directly; keep all info related to the bug in the database unless requested to do otherwise.

------------------------------
What exactly was the workaround?

I did try removing the statement, and it kept reading the STDIN with the
fread until the amount, in this case being 128 bytes is filled, rather than
taking it to the end of the packet...
 [2003-09-17 18:37 UTC] wez@php.net 
What you have just described is blocking IO, and that is precisely what I'd expect to happen when reading from STDIN.

Now, when reading from a socket, you would expect the call to return at the end of a packet, but php doesn't yet have any idea that stdin is a socket, and that sounds like the cause of your problems.

Can you confirm that this is the case, as your more recent comments don't seem to match up to your original report?
 [2003-09-18 04:15 UTC] bill at baghead dot co dot uk 
The case is with the original code stated, the code loops, and does not block on the fread - ie, it keeps returning instantly (even with nothing), which seems to me to be non blocking eventhough I'd told it to block..

If I remove the stream_set_blocking(STDIN,TRUE); altogether, fread appears to block - but instead of returning after receiving a block of data, it blocks until the buffer is filled up (in this case being 128 bytes) - *then* it returns..
 [2003-09-24 21:41 UTC] robert at interjinn dot com 
I've been directed here from bug #25616 with the indication that this is the same bug. I read this bug before I posted bug #25616 and the issues seems different. This one describes an issue with blocking mode, my bug describes an issue whith the script exitting successfully while in an infinite loop, which is contrary to the expected functionality of a while( 1 ) loop. I'm not sure why I was pointed here. Albeit my bug seemed to come into existence with the use of stream_set_blocking( $stdin, FALSE )
 [2003-11-28 17:46 UTC] wez@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

Just committed a probable fix; please try the next snapshot.
 [2003-12-16 09:53 UTC] bill at baghead dot co dot uk 
Using the latest snapshop, it still shows the same problem..

Cheers - Bill.
 [2004-01-14 09:49 UTC] wez@php.net 
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip
 [2004-01-19 14:11 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