From the stream_select() manual page:

The streams listed in the read array will be watched to see if characters become available for reading (more precisely, to see if a read will not block - in particular, a stream resource is also ready on end-of-file, in which case an fread() will return a zero length string). 

I believe that under the OS and PHP version given in the headers of this report, the stream timeout function is not working when used with fgets as well.  However, I will load the current PHP on the box and test again, to ensure I provide you with accurate and complete information and I'll open a new pr if necessary.

Let's close this one as Bogus.

I have now tested this using both PHP 4.3.11 and 5.0.4, and the bug remains.  My same prior notes apply.  Please review.

After testing with the latest php5 release, this still has a problem.  Let me try to be more succinct in summarizing...

When operating with wrapper_type of 'plainfile' (such as when tailing one or more files), the tv_sec and tv_usec (timeout) are ignored... because stream_select insists on classifying FEOF as an important event.  While this may be true for a socket event (socket close, for example... which is why we have socket_select instead), it is not true for a plainfile event.

Ask yourself this question -- How would you make use of the 'timeout' parameter when reading from a plainfile wrapper?  It would never come into play if FEOF awakens the stream_select call!  The purpose of stream_select is to let you multiplex streams... so you can WAIT for an action to take place on a stream (or a timeout).  If FEOF is allowed to awaken the select (rather than waiting for a timeout or for data to become available), then there's not much point to using that call...  You're forcing it to do [expensive] polling instead of relying on the select() interrupt structure to do the work for you.

My second argument is this:  Let's assume you insist FEOF should awaken the select.  If that's the case, then it still is not working correctly... because if I *add data* to a file after the select detected EOF, and then do a select again, it *still* thinks no data is available (and that we're still at EOF even though we're not).

This is VERY broken.

Assigning to Sara who knows this stuff..

Please try using this CVS snapshot:

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

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Its been like a year since im waiting for this to be fixed!

Sorry, but your problem does not imply a bug in PHP itself.  For a
list of more appropriate places to ask for help using PHP, please
visit http://www.php.net/support.php as this bug system is not the
appropriate forum for asking support questions.  Due to the volume
of reports we can not explain in detail here why your report is not
a bug.  The support channels will be able to provide an explanation
for you.

Thank you for your interest in PHP.

This is expected behavior.

From PHP manual: The streams listed in the read  array will be watched to see if characters become available for reading (more precisely, to see if a read will not block [...]).

A read from a regular file will virtually never block, it will return an empty string instead. Actually stream_select() is only meant to be used with sockets, pipes, etc.