ID: 25575
Updated by: [EMAIL PROTECTED]
Reported By: bill at baghead dot co dot uk
Status: Feedback
Bug Type: Sockets related
Operating System: Redhat 9
PHP Version: 4CVS-2003-09-17 (stable)
New Comment:
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?
Previous Comments:
------------------------------------------------------------------------
[2003-09-17 18:35:41] [EMAIL PROTECTED]
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 13:14:14] [EMAIL PROTECTED]
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 12:49:37] 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 11:57:45] [EMAIL PROTECTED]
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 11:13:43] 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.
------------------------------------------------------------------------
--
Edit this bug report at http://bugs.php.net/?id=25575&edit=1
