Edit report at https://bugs.php.net/bug.php?id=47918&edit=1
ID: 47918
Updated by: ab@php.net
Reported by: RQuadling at GMail dot com
Summary: stream_set_blocking() does not work with pipes
opened with proc_open()
-Status: Open
+Status: Wont fix
Type: Bug
Package: Streams related
Operating System: Windows
PHP Version: 5.*, 6CVS (2009-06-19
Block user comment: N
Private report: N
New Comment:
I have to disappoint here, the anonymous pipes are plain file descriptors, they don't support
asynchronous mode on Windows. The following page sheds more light on this:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365141%28v=vs.85%29.aspx
Because of them being file descriptors, they're also not supported by select() which requires
SOCKETS.
Please take in account the solution brought by bug #51800 . Pipe descriptors MUST be read
simultaneously. In this regard, bug #63922 and bug #44908 can be closed as well as they regard to
the Windows APIs behaviors which cannot be changed.
Thanks.
Previous Comments:
------------------------------------------------------------------------
[2014-06-06 20:26:06] cxjohnson at gmail dot com
Or more precisely, stream_get_meta_data() is broken. It reports the mode as blocked, yet a read on
the pipe while after stream_set_blocking($pipe, 0) does NOT block, as would be expected.
------------------------------------------------------------------------
[2014-06-06 20:15:53] cxjohnson at gmail dot com
Still broken in 5.4+.
This fails in the same way on Mac OSX 10.9.3 with PHP 5.4.24, and on FreeBSD 9.2-RELEASE with PHP
5.4.25.
------------------------------------------------------------------------
[2012-09-21 14:40:56] schmod at gmail dot com
Is this really true?
I can run a number of console applications via proc_open() without encountering
blocking on win32.
However, I have encountered a number of applications that will cause PHP hang on
fread() until the process closes (regardless of whether or not the buffer has filled).
This needs to either be categorized as a bug, or the documentation needs to be updated
to explain this unexpected behavior on win32.
PHP 5.4.3/Win7x64.
------------------------------------------------------------------------
[2009-08-24 08:59:40] RQuadling at GMail dot com
Essentially, non-blocking streams don't exist in win32 PHP.
They work fine for non-win32, so maybe this should become a feature
request.
From reading the MSDN sites regarding non-blocking/blocking, it seems
that a completely different mechanism for file handling needs to be
used.
Other scripting languages have solved this issue in a different fashion,
using an additional thread to process the stream.
------------------------------------------------------------------------
[2009-08-22 05:51:48] nobodyy at mailinator dot com
Same problem here...
If we use proc_open and the output (pipes[1]) is greater than 2kb,
the application just gets stuck!
I don't have any idea why, but it is never terminated, unless we do
an FREAD of FGETS at the pipe[1].
But we can't do the FGETS if we don't know if there is content to be
read. There is when stream_set_blocking should save the day.. But it
doesn't work! :(
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
https://bugs.php.net/bug.php?id=47918
--
Edit this bug report at https://bugs.php.net/bug.php?id=47918&edit=1