Further reduce the block size that LLProcess writes to child pipe.

It seems that on Windows, even 32K is too big: one in three load-test runs
fails with a duplicated block. Empirically, reducing it to 4K makes it much
more stable -- at least we can run successfully 100 consecutive times, which
is a step in the right direction.

1 files changed, 9 insertions, 2 deletions

diff --git a/indra/llcommon/llprocess.cpp b/indra/llcommon/llprocess.cpp
index d926791e9e..178ec064c0 100644
--- a/indra/llcommon/llprocess.cpp
+++ b/indra/llcommon/llprocess.cpp
@@ -181,8 +181,15 @@ public:
 				{
 					// Tackle the current buffer in discrete chunks. On
 					// Windows, we've observed strange failures when trying to
-					// write big lengths (~1 MB) in a single operation.
-					std::size_t towrite((std::min)(remainlen, std::size_t(32*1024)));
+					// write big lengths (~1 MB) in a single operation. Even a
+					// 32K chunk seems too large. At some point along the way
+					// apr_file_write() returns 11 (Resource temporarily
+					// unavailable, i.e. EAGAIN) and says it wrote 0 bytes --
+					// even though it did write the chunk! Our next write
+					// attempt retries with the same chunk, resulting in the
+					// chunk being duplicated at the child end. Using smaller
+					// chunks is empirically more reliable.
+					std::size_t towrite((std::min)(remainlen, std::size_t(4*1024)));
 					apr_size_t written(towrite);
 					apr_status_t err = apr_file_write(mPipe, remainptr, &written);
 					// EAGAIN is exactly what we want from a nonblocking pipe.