Description: ------------ "POSIX.1-2001 says that write(2)s of less than PIPE_BUF bytes must be atomic: the output data is written to the pipe as a contiguous sequence. Writes of more than PIPE_BUF bytes may be non-atomic: the kernel may interleave the data with data written by other processes." Most operating systems have PIPE_BUF as 4096 bytes. Setting CHUNK_SIZE to 8192 may cause php to do two 4k writes which can cause Crypt_GPG to hang forever. It hangs because $fdInput is returned as writable by stream_select(), the first 4k write succeeds (fully or partially) but because php will try to write the next 4k chunk it hangs as the fd is full and hasn't beed re-selected to test if it can be written. The other option is to set all file descriptors as non-blocking using stream_set_blocking(), the code correctly increments the buffers for the actual amount written/read. This will also fix bug 18526

Andy, thanks for your detailed report. When developing the file streaming operations for Crypt_GPG I tested a lot using strace to see what the buffer size used by PHP is. It seems PHP always reads in 8k chunks no matter what chunk size you specify. If you specify 4k chunks, PHP reads one 8k chunk and the next read comes from an internal buffer in PHP. Of course, this may be different for writes. Your description certainly sounds correct and I will have to do more testing to verify PHP itself works properly.

Bug #18526 is a duplicate of this issue.

Fixed in SVN in http://svn.php.net/viewvc?view=revision&revision=316510. I will do a release this week. Out of curiosity, on what OS, kernel version and PHP version are you experiencing the issue? I was unable to reproduce it on Ubuntu Linux using a chunk size of 8192. Using higher-chunk sizes reproduced the issue so I was able to test it. In the end, I left the chunk size at 8192. PHP does some internal buffering of the streams and uses 8192 as its chunk size. Using larger chunks made things considerably slower. The delay mechanism included in the commit gives a nice speed boost though :) Thanks again for your bug report!

Ok, I tested on FreeBSD 8.2 on a VM and easily reproduced the issue. Setting the chunk size to 4096 prevented hanging but was extremely slow. After the fix from SVN r316510, the 8192 chunk size works and the speed is excellent.