Backed out changeset 51205a909e2c (Windows APR pipe bug workaround)

If in fact we've managed to fix the APR bug writing to a Windows named pipe,
it should no longer be necessary to try to work around it by testing with a
much smaller data volume on Windows!

1 files changed, 3 insertions, 28 deletions

diff --git a/indra/llcommon/tests/llleap_test.cpp b/indra/llcommon/tests/llleap_test.cpp
index e01aedd7ee..1b71f7fb72 100644
--- a/indra/llcommon/tests/llleap_test.cpp
+++ b/indra/llcommon/tests/llleap_test.cpp
@@ -41,30 +41,7 @@ StringVec sv(const StringVec& listof) { return listof; }
 #define sleep(secs) _sleep((secs) * 1000)
 #endif
 
-#if ! LL_WINDOWS
-const size_t BUFFERED_LENGTH = 1023*1024; // try wrangling just under a megabyte of data
-#else
-// "Then there's Windows... sigh." The "very large message" test is flaky in a
-// way that seems to point to either the OS (nonblocking writes to pipes) or
-// possibly the apr_file_write() function. Poring over log messages reveals
-// that 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 the same
-// chunk, resulting in the chunk being duplicated at the child end, corrupting
-// the data stream. Much as I would love to be able to fix it for real, such a
-// fix would appear to require distinguishing bogus EAGAIN returns from real
-// ones -- how?? Empirically this behavior is only observed when writing a
-// "very large message". To be able to move forward at all, try to bypass this
-// particular failure by adjusting the size of a "very large message" on
-// Windows. When the test fails at BUFFERED_LENGTH, the test_or_split()
-// function performs a binary search to find the largest size that will work.
-// Running several times on a couple different Windows machines produces a
-// range of "largest successful size" results... suggesting that it may be a
-// matter of available OS buffer space? In any case, pick something small
-// enough to be optimistic, while hopefully remaining comfortably larger than
-// real messages we'll encounter in the wild.
-const size_t BUFFERED_LENGTH = 256*1024;
-#endif  // LL_WINDOWS
+const size_t BUFFERED_LENGTH = 1024*1023; // try wrangling just under a megabyte of data
 
 void waitfor(const std::vector<LLLeap*>& instances, int timeout=60)
 {
@@ -668,13 +645,11 @@ namespace tut
                         std::upper_bound(sizes.begin(), sizes.end(), 0, tester);
                     if (found != sizes.end() && found != sizes.begin())
                     {
-                        std::cout << "test_large_message(" << *(found - 1)
-                                  << ") is largest that succeeds" << std::endl;
+                        std::cout << "test_large_message(" << *(found - 1) << ") is largest that succeeds" << std::endl;
                     }
                     else
                     {
-                        std::cout << "cannot determine largest test_large_message(size) "
-                                  << "that succeeds" << std::endl;
+                        std::cout << "cannot determine largest test_large_message(size) that succeeds" << std::endl;
                     }
                 }
                 catch (const failure&)