I tried both 0 and False to set non blocking mode. In all cases the 
function returns false and the meta data reports that the pipe is 
still in blocking mode.

I've just tried it with PHP 5.2.8 (cli) (built: Dec  8 2008 19:31:23) 
(on Windows XP SP3) on my home laptop and the same problem.

I also tried opening the pipes descriptors like ...

$a_Descriptors = array(0 => array('pipe', 'rn'), 1 => array('pipe', 
'wn'), 2 => array('pipe', 'wn'));

but no change.

Only worry about 5.3+

If it exists below 5.3, the version must state it! Do NOT touch it 
again.

I tested this on PHP 5.3 (on Linux) and duplicated the error that the print_r command shows blocking as true. HOWEVER, the stream does not block when actually tested... a simple test script can be created by adding a line and slightly modifying the scripts found at:

http://bugs.php.net/bug.php?id=49084

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! :(

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.

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.

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.

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.

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.

There is now a workaround for this issue on Windows for all versions of PHP (and other scripting languages with similar problems).

https://github.com/cubiclesoft/createprocess-windows

Before calling proc_open(), start a TCP/IP server in your PHP userland code.  Then pass the IP address and port number to 'createprocess.exe' using the /socketip and /socketport options and use the /w /stdin=socket /stdout=socket /stderr=socket options as well.  Three TCP/IP connections will be established from 'createprocess.exe' and the first byte of data on each stream indicates the file descriptor associated with the stream (0x00 = stdin, 0x01 = stdout, 0x02 = stderr).  The sockets are passed to the final process via the standard handles that 'createprocess.exe' then runs.  The /w option waits for the target process to complete before closing the TCP/IP sockets and exiting.

After each TCP/IP connection has been established and the first byte of data has been received, you can enable non-blocking mode and then proceed as if they were normal, non-blocking pipes on other OSes.

Read the following StackOverflow post if you want to learn more about how this works/is possible:

http://stackoverflow.com/questions/4993119/redirect-io-of-process-to-windows-socket

Tip:  Use "tcp://127.0.0.1:0" in the call to stream_socket_server() to get a random port number assigned to the listening socket (the :0 part) and basically guarantee that the call won't fail.  Then use stream_socket_get_name($fp, false) to retrieve the 'IP:port' associated with the socket to retrieve the port number that was assigned by the OS.