merge changes for latest fixes from nat and callum

1 files changed, 0 insertions, 17 deletions

diff --git a/indra/llcommon/tests/llleap_test.cpp b/indra/llcommon/tests/llleap_test.cpp
index 653b043de4..2d88e2c676 100755
--- a/indra/llcommon/tests/llleap_test.cpp
+++ b/indra/llcommon/tests/llleap_test.cpp
@@ -38,24 +38,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.
-const size_t BUFFERED_LENGTH = 65336;
-#endif  // LL_WINDOWS
 
 void waitfor(const std::vector<LLLeap*>& instances, int timeout=60)
 {